* Merlin Moncure (mmonc...@gmail.com) wrote: > 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.
I have to side with what I believe is Tom's position on this one. I do like the notion of throwing an error in cases where someone sent us something that we're pretty sure is wrong, but I don't agree that we should continue to carry on bug-compatibility with things that are already one foot in the grave and really just need to be shoved all the way in. This isn't the only break in backwards compatibility we've had over the years and is pretty far from the largest (string escaping, anyone? or removing implicit casts?) and I'd argue we're better off for it. Thanks! Stephen
signature.asc
Description: Digital signature
