Date: Wed, 23 Mar 2016 16:18:56 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Regina Obe <lr@pcorp.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: PostgreSQL 9.6 behavior change with set returning
 (funct).*
Message-ID: <20160323201856.GR3127@tamriel.snowman.net>
References: <001201d18524$f84c4580$e8e4d080$@pcorp.us>
 <9987.1458754648@sss.pgh.pa.us>
 <CAHyXU0zeaHigirhGXk5Go-=riu+ZSuiSa_kyLpgEaorSM8iAFg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="EqMiG03fNEfpmvTL"
Content-Disposition: inline
In-Reply-To: 
 <CAHyXU0zeaHigirhGXk5Go-=riu+ZSuiSa_kyLpgEaorSM8iAFg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--EqMiG03fNEfpmvTL
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* 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?
>=20
> 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:
>=20
> ysanalysis=3D# select unnest(current_schemas(true));
>    unnest
> =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80
>  pg_catalog
>  public
>=20
> 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

--EqMiG03fNEfpmvTL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJW8vovAAoJEO1sijiDR2RVPxkP/1cDVlK3W611vlVkQHtcFNTd
YJSXjx9dn9/oUiabpxB/fisrNk2vRl20jYIGmVvjpJWT1ShJK3r3twujGdY3LuLZ
LqeQVFkbSRaF+oK9pWIqoHHc/xryuXYHAmQxCHETO9KUM214h0lnNHNdLMtjEH1f
fmJRTa5lSrX2xGCr4rSceyja1lYc29cnlCLHK+i2mi2iTnG5boE+dTURBB0IjiTk
Y8IjsT4LHZyCC4szNT9plHZsXOCRi0P9sVTc3eQl1FiwO/PjueEdL+FTkCHQfgf1
wPZC55SG7PHje76Y1b5ixJaue94bvdVbxamtEN5eOek0Ir+UEeTII3iJDwUKcI8S
pjOaN0hXvjSCWp6WuBaRkQFdbZwpBIYfvKovackA0baxDSyiU6t1WtFfihDSgomA
qXIyegbeeHHNtxCc6OcaYUoEUBhQGg6xRM3gBReXZb0YaztzrnRIGSMgnINombkh
W0wSbag53/J8n+pG1yKQqdkMkl1+BNtDiscDhnt4iSXfdkPXwaHKm6wZpNz7QIQX
jf9IdnjlNPojWkpOS7ZTGRd4SdT341IM4EnB0NGBOFZ0br4rAVKb7LGqOdlrOHYw
hzgdIlNnX37HXyQ0XSwJSUjNUr9F0EQwIVPGpVvTSOKY3MJ/MKS9h23wlmwS1Vfg
//aZYlFjHIAlbK/iGplU
=bd23
-----END PGP SIGNATURE-----

--EqMiG03fNEfpmvTL--