On Tue, 13 Jul 2021 at 06:50, Peter Eisentraut
wrote:
> Your version looks better to me than the original version, but I'm still
> -0.05 on changing this at all.
I was more +0.4. It does not seem worth the trouble of too much
discussion so, just to try and bring this to a close, instead of
addin
On 12.07.21 10:44, David Rowley wrote:
What I was trying to get to here was something that was more
reasonable that might make sense to commit. I'm just not certain
where Peter stands on this now that the latest patch is a net zero
when it comes to adding lines. Peter?
Your version looks bette
On Mon, 12 Jul 2021 at 16:48, Greg Nancarrow wrote:
>
> On Mon, Jul 12, 2021 at 2:26 PM David Rowley wrote:
> >
> > > It seems strange to add a comment to explain why it's there. If we're
> > > going to the trouble of doing that, then we should just remove it and
> > > add a very small comment to
On Mon, Jul 12, 2021 at 2:26 PM David Rowley wrote:
>
> > It seems strange to add a comment to explain why it's there. If we're
> > going to the trouble of doing that, then we should just remove it and
> > add a very small comment to mention why INT8 sequences don't need to
> > be checked.
>
> Any
On Wed, 7 Jul 2021 at 20:37, David Rowley wrote:
>
> On Wed, 7 Jul 2021 at 00:06, Greg Nancarrow wrote:
> > I think if you're going to reject this patch, a brief comment should
> > be added to that code to justify why that existing superfluous check
> > is worthwhile.
>
> It seems strange to add
On Wed, 7 Jul 2021 at 00:06, Greg Nancarrow wrote:
> I think if you're going to reject this patch, a brief comment should
> be added to that code to justify why that existing superfluous check
> is worthwhile.
It seems strange to add a comment to explain why it's there. If we're
going to the trou
On Tue, Jul 6, 2021 at 8:43 PM David Rowley wrote:
>
> On Sun, 4 Jul 2021 at 20:53, David Rowley wrote:
> >
> > On Sat, 3 Jul 2021 at 22:44, Peter Eisentraut
> > wrote:
> > > I don't think this is a good change.
> >
> > > I think we should leave it as is.
> >
> > I'm inclined to agree.
>
> Does
On Sun, 4 Jul 2021 at 20:53, David Rowley wrote:
>
> On Sat, 3 Jul 2021 at 22:44, Peter Eisentraut
> wrote:
> > I don't think this is a good change.
>
> > I think we should leave it as is.
>
> I'm inclined to agree.
Does anyone object to marking this patch as rejected in the CF app?
David
On Sat, 3 Jul 2021 at 22:44, Peter Eisentraut
wrote:
> I don't think this is a good change.
> I think we should leave it as is.
I'm inclined to agree.
When I mentioned adding a comment I'd not imagined it would be quite
so verbose. Plus, I struggle to imagine there's any compiler out there
that
On 21.06.21 13:32, Greg Nancarrow wrote:
On Mon, Jun 21, 2021 at 8:32 PM David Rowley wrote:
It might be worth putting in a comment to mention that the check is
not needed. Just in case someone looks again one day and thinks the
checks are missing.
Probably best to put this in the July commi
Those code comments look good.
On Mon, Jun 21, 2021 at 8:32 PM David Rowley wrote:
>
> It might be worth putting in a comment to mention that the check is
> not needed. Just in case someone looks again one day and thinks the
> checks are missing.
>
> Probably best to put this in the July commitfest so it does not get missed.
On Mon, 21 Jun 2021 at 22:10, Greg Nancarrow wrote:
> Sequence MINVALUE/MAXVALUE values are read into "int64" variables and
> then range-checked according to the sequence data-type.
> However, for a BIGINT sequence, checking whether these are <
> PG_INT64_MIN or > PG_INT64_MAX always evaluates to
Hi,
Sequence MINVALUE/MAXVALUE values are read into "int64" variables and
then range-checked according to the sequence data-type.
However, for a BIGINT sequence, checking whether these are <
PG_INT64_MIN or > PG_INT64_MAX always evaluates to false, as an int64
can't hold such values.
I've attached
14 matches
Mail list logo
