I'm starting to think this might not actually be my mistake, but be a very narrow issue w/ the expanded object code.
So, I've added support for converting postgis in-memory objects into expanded outputs, and have overwritten the usual lwgeom_to_gserialized() function with one that creates an expanded object. I haven't done anything to actually handle expanded objects on input, but as I understand it, that's fine, everything is supposed to work as normal when handed expanded objects. And thus far, that has been true, almost all regression tests work fine. But here's my narrow case. This works fine with the old lwgeom_to_gserialized that uses standard flat varlena outputs. It does the following w/ expanded outputs. SELECT gid FROM test_table ORDER BY st_distance(geom, 'POINT(-305 998.5)'::geometry) LIMIT 5; ERROR: could not find pathkey item to sort Tracing through the debugger, I see the lwgeom_to_gserialized() function get hit once for the geometry literal, via parse_analyze. After that, the error shows up shortly. If I change the query ever so slightly, adding a geometry output column: SELECT gid, geom FROM test_table ORDER BY st_distance(geom, 'POINT(-305 998.5)'::geometry) LIMIT 5; It runs through to completion, five records returned. As long as the query includes a geometry output on the output line, it works. A function that uses a geometry, but not doesn't actually output it, will still fail, with the same pathkey error. This will fail, for example. SELECT gid, ST_AsText(geom) FROM test_table ORDER BY st_distance(geom, 'POINT(-305 998.5)'::geometry) LIMIT 5; So I'm wondering what I should debug next. My code is hardly being touched at all at this point, and I'm very confident it's memory clean, etc (the flattener raises hell if the output is shorter or longer than the expected allocation). Any pointers as to what to look for, much appreciated. P. -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers