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
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) |