Re: PostgreSQL 9.6 behavior change with set returning (funct).*

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Regina Obe <lr(at)pcorp(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
Date: 2016-03-23 18:47:35
Message-ID: CAHyXU0zeaHigirhGXk5Go-=riu+ZSuiSa_kyLpgEaorSM8iAFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> which is both SQL-standard semantics and much more efficient than
> SRF-in-tlist. We've more or less deprecated SRF-in-tlist since we
> introduced LATERAL in 9.3. How much are we willing to do to stay
> bug-compatible with old behaviors here?

I think we should, and the fact this was caught so early on the
release cycle underscores that. One of the problems is that there are
reasonable cases (note, not impacted by this bug) of this usage that
are still commonplace, for example:

ysanalysis=# select unnest(current_schemas(true));
unnest
────────────
pg_catalog
public

I'm something of a backwards compatibility zealot, but I've become one
for very good reasons. Personally, I'd rather we'd define precisely
the usages that are deprecated (I guess SRF-tlist in the presence of
FROM) and force them to error out with an appropriate HINT rather than
give a different answer than they used to. The problem here is that
LATERAL is still fairly new and there is a huge body of code out there
leveraging the 'bad' way, as it was for years and years the only way
to do a number of useful things.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2016-03-23 18:52:24 Re: Relation extension scalability
Previous Message Peter Geoghegan 2016-03-23 18:40:22 Re: Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)