Re: [HACKERS] CTE inlining - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] CTE inlining
Date
Msg-id 17491.1494358602@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] CTE inlining  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: [HACKERS] CTE inlining  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Tue, May 9, 2017 at 12:15 PM, Peter Eisentraut <
> peter.eisentraut@2ndquadrant.com> wrote:
>> If we just tell them that the thing they might have relied on might go
>> away, without a replacement to suggest, then we're just confusing and
>> scaring them, no?

> ​We'd end up suggesting our OFFSET 0 hack as true protection.

Considering that many of the commenters in this thread view OFFSET 0
as a vile hack that ought to go away, I can hardly see how that's
an improvement.

I tend to agree with Peter that there's no need to do anything until
we have a committable code improvement.  Documentation changes that
push people towards adding OFFSET 0, without any certainty that that
will be the long-term answer, do not seem like a net positive.

Also, considering that this behavior has been there since 8.4,
I think it's sheerest chutzpah to claim that changing the docs in
v10 would materially reduce the backward-compatibility concerns
for whatever we might do in v11.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal psql \gdesc
Next
From: Stas Kelvich
Date:
Subject: Re: [HACKERS] Logical replication ApplyContext bloat