On Tue, May 22, 2018 at 5:59 AM, Robert Haas wrote:
> If we start routinely
> back-patching things that fall into that category, we will certainly
> manage to destabilize older releases on a regular basis.
>
Just because something is bad if done in excess doesn't mean specific
moderate partaking
On Sun, May 20, 2018 at 5:16 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>> The risk here is significantly reduced since the existing user-visible
>> behavior is an error which presumably no one is relying upon. Between that
>> and being able to conform to the standard syntax for a long-st
> "Stephen" == Stephen Frost writes:
Stephen> Just to be clear, based on what I saw on IRC, this
Stephen> specifically came out of someone complaining that it didn't
Stephen> work and caused difficulty for them.
Specifically, as I said at the start, it's from bug #15200, see
http://postgr
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> Whether or not Andrew's patch is formally classified as a bug fix is
> subjective. I'm inclined to accept it as a bug fix, but I also think
> that it shouldn't matter very much. The practical implication is that
> I don't think it's completely o
"David G. Johnston" writes:
> The risk here is significantly reduced since the existing user-visible
> behavior is an error which presumably no one is relying upon. Between that
> and being able to conform to the standard syntax for a long-standing
> feature I would say the benefit outweighs the
On Sun, May 20, 2018 at 1:13 PM, Peter Geoghegan wrote:
> There have been
> cases where we chose to not back-patch an unambiguous bug fix even
> though it was clear that incorrect user-visible behavior remained.
>
The risk here is significantly reduced since the existing user-visible
behavior i
On Sat, May 19, 2018 at 4:41 PM, Tom Lane wrote:
> It may be that this fix is simple and safe enough that the risk/reward
> tradeoff favors back-patching, but I think you have to argue it as a
> favorable tradeoff rather than just saying "this isn't per standard".
> Consider: if Andrew had complet
On Sun, May 20, 2018 at 01:39:27AM +0100, Andrew Gierth wrote:
> > "Tom" == Tom Lane writes:
>
> >> I'm +1 for backpatching it. It may be operating as designed by
> >> PeterE ten years ago, but it's not operating as designed by the SQL
> >> standard.
>
> Tom> By that argument, *anyplace*
On 20/05/18 05:25, Andrew Gierth wrote:
> +select_fetch_first_value:
> + c_expr
> { $$ = $1; }
> + | '+' I_or_F_const
> + { $$ = (Node *) makeSimpleA_Expr(AEXPR_OP,
On 20/05/18 01:41, Tom Lane wrote:
> Vik Fearing writes:
>> On 20/05/18 00:57, Tom Lane wrote:
>> I'm +1 for backpatching it. It may be operating as designed by PeterE
>> ten years ago, but it's not operating as designed by the SQL standard.
>
> By that argument, *anyplace* where we're missing a
Updated patch.
This one explicitly accepts +/- ICONST/FCONST in addition to c_expr for
both offset and limit, removing the inconsistencies mentioned
previously.
I changed the wording of the docs part a bit; does that look better? or
worse?
Old behavior:
select 1 offset +1 rows; -- ERROR: synta
> "Tom" == Tom Lane writes:
>> I'm +1 for backpatching it. It may be operating as designed by
>> PeterE ten years ago, but it's not operating as designed by the SQL
>> standard.
Tom> By that argument, *anyplace* where we're missing a SQL-spec
Tom> feature is a back-patchable bug. I don'
> "Tom" == Tom Lane writes:
Tom> Also, why'd you back off "must write" to "should write" in the docs?
Tom> This doesn't make the parens any more optional than before.
Currently, the requirement for parens is inconsistent - FETCH FIRST
wants them for absolutely anything that's not a literal
On Sat, May 19, 2018 at 07:41:10PM -0400, Tom Lane wrote:
> Vik Fearing writes:
>> I'm +1 for backpatching it. It may be operating as designed by PeterE
>> ten years ago, but it's not operating as designed by the SQL standard.
>
> By that argument, *anyplace* where we're missing a SQL-spec featu
Vik Fearing writes:
> On 20/05/18 00:57, Tom Lane wrote:
>> Also, why'd you back off "must write" to "should write" in the docs?
>> This doesn't make the parens any more optional than before.
> It certainly does. It allows this now:
> PREPARE foo AS TABLE bar FETCH FIRST $1 ROWS ONLY;
No, it ma
On 20/05/18 01:27, Vik Fearing wrote:
>> Also, why'd you back off "must write" to "should write" in the docs?
>> This doesn't make the parens any more optional than before.
>> It certainly does. It allows this now:
>
> PREPARE foo AS TABLE bar FETCH FIRST $1 ROWS ONLY;
Please disregard this comm
On 20/05/18 00:57, Tom Lane wrote:
> Andrew Gierth writes:
>> Attached is a draft patch for fixing that, which additionally fixes the
>> ugly wart that OFFSET ROW/ROWS and FETCH FIRST [] ROW/ROWS ONLY
>> had very different productions for ; both now accept c_expr there.
>
> LGTM, except please s
Andrew Gierth writes:
> Attached is a draft patch for fixing that, which additionally fixes the
> ugly wart that OFFSET ROW/ROWS and FETCH FIRST [] ROW/ROWS ONLY
> had very different productions for ; both now accept c_expr there.
LGTM, except please s/presense/presence/ in grammar comment.
Also
Per bug #15200, our support for sql2008 FETCH FIRST syntax is incomplete
to the extent that it should be regarded as a bug; the spec quite
clearly allows parameters/host variables in addition to constants, but
we don't.
Attached is a draft patch for fixing that, which additionally fixes the
ugly w
19 matches
Mail list logo
