RE: Regression on PostgreSQL 10 ORDER/GROUP BY expression not found in targetlist

Regina Obe <lr@pcorp.us>

From: "Regina Obe" <lr@pcorp.us>
To: "'David Rowley'" <david.rowley@2ndquadrant.com>
Cc: "'PostgreSQL-development'" <pgsql-hackers@postgresql.org>
Date: 2018-06-29T17:30:03Z
Lists: pgsql-hackers
> On 29 June 2018 at 21:06, Regina Obe <lr@pcorp.us> wrote:
> > 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;
> 
> Can you try in REL_10_STABLE? There was a fix committed [1] for something
> very similar just a week ago.
> 
> [1]
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a4c95b0b80
> c70677c09c0d5c82a6fba875160288
> 
> --
>  David Rowley                   http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services

Thanks for this input.  I guess I was mistaken about the commit that caused this
and it's most likely this one since this one fails as well.

Here is a trivial example to exercise that doesn't involve PostGIS.

CREATE TABLE edge AS SELECT 1 AS edge_id;
SELECT 't3280', 'L1b' || generate_series(1,10) 
FROM edge
ORDER BY 1;


Now that said, I think I should change our test since it's using questionable assumptions anyway.
My only concern with this issue is that it's behavior that was allowed before in 10 a stable branch
and it's changing in a micro release.

I doubt few others would be bitten by though, but probably still worthwhile to put a note about it in the upcoming release notes
if this new behavior is kept.

Thanks,
Regina Obe




Commits

  1. Fix create_scan_plan's handling of sortgrouprefs for physical tlists.

  2. Add PGTYPESchar_free() to avoid cross-module problems on Windows.

  3. Fix mishandling of sortgroupref labels while splitting SRF targetlists.