On June 26th, our PostGIS debian bot started failing on PostgreSQL 10 with
one of our regression tests for topology.
It started erroring out with
ORDER/GROUP BY expression not found in targetlist
Related ticket here: https://trac.osgeo.org/postgis/ticket/4111
I think the exact query that is triggering it is this one though I don't
have PostgreSQL 10 head installed locally to confirm.
SELECT 't3280', 'L1b' || topology.TopoGeo_AddLinestring('bug3280', geom)
FROM bug3280.edge where edge_id = 1
ORDER BY 1;
This bot follows the dev, and stable git branches of PostgreSQL, and it was
on PostgreSQL 10 that it started failing.
PostgreSQL 11 was okay.
I'm assuming this is an unintended consequence of this commit
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3566873f2
1909397561418fab22c98332fa8b72a
as that's when the issue started happening.
Just want to confirm that and not something in our code we've just been
doing incorrectly.
If needed I'll try to put together an example that doesn't involve PostGIS
to exercise the problem.
-- more details from the commit and it seemed like lots of files were
changed
Add PGTYPESchar_free() to avoid cross-module problems on Windows.
(details)
Commit 3566873f21909397561418fab22c98332fa8b72a by tmunro
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3566873f2
1909397561418fab22c98332fa8b72a
Add PGTYPESchar_free() to avoid cross-module problems on Windows.
On Windows, it is sometimes important for corresponding malloc() and
free() calls to be made from the same DLL, since some build options can
result in multiple allocators being active at the same time. For that
reason we already provided PQfreemem(). This commit adds a similar
function for freeing string results allocated by the pgtypes library.
Author: Takayuki Tsunakawa Reviewed-by: Kyotaro Horiguchi Discussion:
https://postgr.es/m/0A3221C70F24FB45833433255569204D1F8AD5D6%40G01JPEXMBYT05
Thanks,
Regina