Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-24 Thread Merlin Moncure
On Wed, Mar 23, 2016 at 3:18 PM, Stephen Frost wrote: > 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

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-24 Thread Tom Lane
Robert Haas writes: > On Wed, Mar 23, 2016 at 6:34 PM, Tom Lane wrote: >> A possibly larger problem is that it causes the SRFs to be evaluated >> before sorting/ordering/limiting. > I'm not sure I understand quite what the problem is here. If you have

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-24 Thread Robert Haas
On Wed, Mar 23, 2016 at 6:34 PM, Tom Lane wrote: > I wrote: >> ... I'd love to >> toss the entire SRF-in-tlist feature overboard one of these years, >> both because of semantic issues like these and because a fair amount >> of code and overhead could be ripped out if it were

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread Regina Obe
> 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

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread Tom Lane
I wrote: > ... I'd love to > toss the entire SRF-in-tlist feature overboard one of these years, > both because of semantic issues like these and because a fair amount > of code and overhead could be ripped out if it were disallowed. > But I don't know how we get to that --- as Merlin says, there's

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread Stephen Frost
* David G. Johnston (david.g.johns...@gmail.com) wrote: > On Wed, Mar 23, 2016 at 2:11 PM, Tom Lane wrote: > > In the meantime I suppose there's a case to be made for preserving > > bug compatibility as much as possible. > > > > So anyway the question is whether to commit the

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread David G. Johnston
On Wed, Mar 23, 2016 at 2:11 PM, Tom Lane wrote: > > ​​ > In the meantime I suppose there's a case to be made for preserving > bug compatibility as much as possible. > > So anyway the question is whether to commit the attached or not. ​+1 for commit - I'll trust Tom on the

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread Tom Lane
Stephen Frost writes: > * Merlin Moncure (mmonc...@gmail.com) wrote: >> 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

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread Stephen Frost
* Merlin Moncure (mmonc...@gmail.com) wrote: > On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane 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

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread Tom Lane
"David G. Johnston" writes: > On Wednesday, March 23, 2016, Tom Lane wrote: >> ... 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?

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread Merlin Moncure
On Wed, Mar 23, 2016 at 12:37 PM, Tom Lane 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

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread David G. Johnston
On Wednesday, March 23, 2016, Tom Lane wrote: > "Regina Obe" > writes: > > In the past couple of weeks our PostGIS tests against PostgreSQL 9.6 dev > > started failing. I traced the issue down to a behavior change in 9.6 > when > > dealing with

Re: [HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread Tom Lane
"Regina Obe" writes: > In the past couple of weeks our PostGIS tests against PostgreSQL 9.6 dev > started failing. I traced the issue down to a behavior change in 9.6 when > dealing with output of set returning functions when used with (func).* > syntax. > CREATE OR REPLACE

[HACKERS] PostgreSQL 9.6 behavior change with set returning (funct).*

2016-03-23 Thread Regina Obe
In the past couple of weeks our PostGIS tests against PostgreSQL 9.6 dev started failing. I traced the issue down to a behavior change in 9.6 when dealing with output of set returning functions when used with (func).* syntax. Here is an example not involving PostGIS. Is this an intentional