From: Stephen Frost <sfrost@snowman.net>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Regina Obe <lr@pcorp.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
Date: Wed, 23 Mar 2016 16:18:56 -0400
Message-ID: <20160323201856.GR3127@tamriel.snowman.net> (raw)
In-Reply-To: <CAHyXU0zeaHigirhGXk5Go-=riu+ZSuiSa_kyLpgEaorSM8iAFg@mail.gmail.com>
References: <001201d18524$f84c4580$e8e4d080$@pcorp.us>
<9987.1458754648@sss.pgh.pa.us>
<CAHyXU0zeaHigirhGXk5Go-=riu+ZSuiSa_kyLpgEaorSM8iAFg@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
* Merlin Moncure (mmoncure@gmail.com) wrote:
> On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane <tgl@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
Attachments:
[application/pgp-signature] signature.asc (818B, ../20160323201856.GR3127@tamriel.snowman.net/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, mmoncure@gmail.com, tgl@sss.pgh.pa.us, lr@pcorp.us
Subject: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
In-Reply-To: <20160323201856.GR3127@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox