On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
