Thread: Missing grammar production for WITH TIES
The syntax for FETCH FIRST allows the <fetch first quantity> to be absent (implying 1). We implement this correctly for ONLY, but WITH TIES didn't get the memo. Patch attached. -- Vik Fearing
Attachment
On 2020-May-18, Vik Fearing wrote: > The syntax for FETCH FIRST allows the <fetch first quantity> to be > absent (implying 1). > > We implement this correctly for ONLY, but WITH TIES didn't get the memo. Oops, yes. I added a test. Will get this pushed immediately after I see beta1 produced. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On 5/18/20 7:03 PM, Alvaro Herrera wrote: > On 2020-May-18, Vik Fearing wrote: > >> The syntax for FETCH FIRST allows the <fetch first quantity> to be >> absent (implying 1). >> >> We implement this correctly for ONLY, but WITH TIES didn't get the memo. > > Oops, yes. I added a test. Will get this pushed immediately after I > see beta1 produced. Thanks! -- Vik Fearing
On 2020-May-18, Alvaro Herrera wrote: > On 2020-May-18, Vik Fearing wrote: > > > The syntax for FETCH FIRST allows the <fetch first quantity> to be > > absent (implying 1). > > > > We implement this correctly for ONLY, but WITH TIES didn't get the memo. > > Oops, yes. I added a test. Will get this pushed immediately after I > see beta1 produced. Done. Thanks! -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, May 18, 2020 at 07:30:32PM -0400, Alvaro Herrera wrote: > Done. Thanks! This has been committed just after beta1 has been stamped. So it means that it won't be included in it, right? -- Michael
Attachment
On 5/19/20 4:36 AM, Michael Paquier wrote: > On Mon, May 18, 2020 at 07:30:32PM -0400, Alvaro Herrera wrote: >> Done. Thanks! > > This has been committed just after beta1 has been stamped. So it > means that it won't be included in it, right? Correct. I don't know why there was a delay, but it also doesn't bother me. -- Vik Fearing
On 2020-May-19, Vik Fearing wrote: > On 5/19/20 4:36 AM, Michael Paquier wrote: > > > This has been committed just after beta1 has been stamped. So it > > means that it won't be included in it, right? > > Correct. Right. > I don't know why there was a delay, but it also doesn't bother me. I didn't want to risk breaking the buildfarm at the last minute. It'll be there in beta2. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Michael Paquier <michael@paquier.xyz> writes:
> On Mon, May 18, 2020 at 07:30:32PM -0400, Alvaro Herrera wrote:
>> Done. Thanks!
> This has been committed just after beta1 has been stamped. So it
> means that it won't be included in it, right?
Right.
regards, tom lane
On Tue, May 19, 2020 at 12:41:39AM -0400, Tom Lane wrote: > Michael Paquier <michael@paquier.xyz> writes: >> This has been committed just after beta1 has been stamped. So it >> means that it won't be included in it, right? > > Right. Still, wouldn't it be better to wait until the version is tagged? My understanding is that we had better not commit anything on a branch planned for release between the moment the version is stamped and the moment the tag is pushed so as we have a couple of days to address any complaints from -packagers. Here, we are in a state where we have between the stamp time and tag time an extra commit not related to a packaging issue. So, if it happens that we have an issue from -packagers to address, then we would have to include c301c2e in the beta1. Looking at the patch committed, that's not much of an issue, but I think that we had better avoid that. -- Michael
Attachment
Michael Paquier <michael@paquier.xyz> writes:
> On Tue, May 19, 2020 at 12:41:39AM -0400, Tom Lane wrote:
>> Michael Paquier <michael@paquier.xyz> writes:
>>> This has been committed just after beta1 has been stamped. So it
>>> means that it won't be included in it, right?
>> Right.
> Still, wouldn't it be better to wait until the version is tagged?
Yeah, that would have been better per project protocol: if a tarball
re-wrap becomes necessary then it would be messy not to include this
change along with fixing whatever urgent bug there might be.
However, I thought the case for delaying this fix till post-wrap was kind
of thin anyway, so if that does happen I won't be too fussed about it.
Otherwise I would've said something earlier on this thread.
regards, tom lane
On 2020-May-19, Tom Lane wrote: > Yeah, that would have been better per project protocol: if a tarball > re-wrap becomes necessary then it would be messy not to include this > change along with fixing whatever urgent bug there might be. > > However, I thought the case for delaying this fix till post-wrap was kind > of thin anyway, so if that does happen I won't be too fussed about it. > Otherwise I would've said something earlier on this thread. In the end, it's a judgement call. In this case, my assessment was that the risk was small enough that I could push after I saw the tarballs announced. In other cases I've judged differently and waited for longer. If the fix had been even simpler, I would have pushed it right away, but my confidence with grammar changes is not as high as I would like. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services