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
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
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
> 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
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
* 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
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
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
* 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
"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?
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
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
"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
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
14 matches
Mail list logo