From: "Regina Obe" <lr@pcorp.us>
To: "'Merlin Moncure'" <mmoncure@gmail.com>,
	"'Tom Lane'" <tgl@sss.pgh.pa.us>
Cc: "'PostgreSQL-development'" <pgsql-hackers@postgresql.org>
References: <001201d18524$f84c4580$e8e4d080$@pcorp.us>
	<9987.1458754648@sss.pgh.pa.us>
 <CAHyXU0zeaHigirhGXk5Go-=riu+ZSuiSa_kyLpgEaorSM8iAFg@mail.gmail.com>
In-Reply-To: 
 <CAHyXU0zeaHigirhGXk5Go-=riu+ZSuiSa_kyLpgEaorSM8iAFg@mail.gmail.com>
Subject: Re: PostgreSQL 9.6 behavior change with set returning (funct).*
Date: Wed, 23 Mar 2016 19:29:17 -0400
Message-ID: <001901d1855b$d1efd910$75cf8b30$@pcorp.us>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
Thread-Index: AQJAOxIDzwvHQDnqJ4Ajaj7StqZwdwFUNQ0KASK9jvOedoftYA==
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


> I'm something of a backwards compatibility zealot, but I've become one fo=
r very good reasons.  Personally, I'd rather we'd define precisely the usag=
es that are deprecated (I guess SRF-tlist in the presence of
> FROM) and force them to error out with an appropriate HINT rather than gi=
ve 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 t=
he 'bad' way, as it was for years > and years the only way to do a number o=
f useful things.

> merlin

FWIW: I prefer Merlin's solution of erroring out rather than returning an u=
nexpected answer and if it's a buggy behavior it should be eradicated.

The reason is this.  For many  the (..).* ORDER BY .. looks equivalent to t=
he lateral.=20=20
More than a trivial amount of my time has been spent explaining to people w=
hy their raster queries are so slow because the SRF is called multiple time=
s and they should switch to LATERAL usage.

So if the old solution is still going to have the same penalty's I would mu=
ch assume just scrap it and break people's code in a clear and noticeable w=
ay they can't ignore.

There is nothing more frustrating than code that still works but gives you =
an answer different than what you are expecting.  Those kind of bugs stay b=
uried for a while.

I think as long as it's noted in the release notes of the breaking change i=
t's fine and called for if it makes your code cleaner and more manageable.

Thanks,
Regina


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers