Dean Rasheed writes:
> On Tue, 21 Jul 2020 at 23:18, Tom Lane wrote:
>> Here's a v4 that syncs numeric in_range() with the new behavior of
>> float in_range(), and addresses your other comments too.
> LGTM.
Pushed. Thanks again for reviewing!
regards, tom lane
On Tue, 21 Jul 2020 at 23:18, Tom Lane wrote:
>
> Here's a v4 that syncs numeric in_range() with the new behavior of
> float in_range(), and addresses your other comments too.
>
LGTM.
Regards,
Dean
I wrote:
> Dean Rasheed writes:
>> I had a look at this, and I think it's mostly in good shape. It looks
>> like everything from the first message in this thread has been
>> resolved, except I don't know about the jsonpath stuff, because I
>> haven't been following that.
> Thanks for the careful
Dean Rasheed writes:
> I had a look at this, and I think it's mostly in good shape. It looks
> like everything from the first message in this thread has been
> resolved, except I don't know about the jsonpath stuff, because I
> haven't been following that.
Thanks for the careful review! Yeah, Al
On Tue, 16 Jun 2020 at 18:24, Tom Lane wrote:
>
> The attached v3 patch fixes these things and also takes care of an
> oversight in v2: I'd made numeric() apply typmod restrictions to Inf,
> but not numeric_in() or numeric_recv(). I believe the patch itself
> is in pretty good shape now, though t
Dean Rasheed writes:
> On Fri, 12 Jun 2020 at 02:16, Tom Lane wrote:
>> * I had to invent some semantics for non-standardized functions,
>> particularly numeric_mod, numeric_gcd, numeric_lcm. This area
>> could use review to be sure that I chose desirable behaviors.
> I think the semantics you'
Vik Fearing writes:
> On 6/12/20 7:00 PM, Tom Lane wrote:
>> If we did that, you'd never see Inf in a
>> standard-conforming column, since SQL doesn't allow unconstrained
>> numeric columns IIRC.
> It does. The precision and scale are both optional.
> If the precision is missing, it's implementa
On 6/12/20 7:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 11, 2020 at 9:16 PM Tom Lane wrote:
>>> We had a discussion recently about how it'd be a good idea to support
>>> infinity values in type numeric [1].
>
>> FWIW, I don't particularly like the idea. Back when I was an
>> app
On Fri, 12 Jun 2020 at 02:16, Tom Lane wrote:
>
> * I had to invent some semantics for non-standardized functions,
> particularly numeric_mod, numeric_gcd, numeric_lcm. This area
> could use review to be sure that I chose desirable behaviors.
>
I think the semantics you've chosen for numeric_mod
Here's a v2 patch:
* Rebased over today's nearby commits
* Documentation changes added
* Sort abbrev support improved per Andrew's suggestions
* Infinities now considered to fail any typmod precision limit,
per discussion with Robert.
regards, tom lane
diff --git a/c
Robert Haas writes:
> On Fri, Jun 12, 2020 at 2:14 PM Tom Lane wrote:
>> Robert Haas writes:
>>> BTW, has there been any thought to supporting a negative scale for the
>>> numeric data type? If you can cut off digits after the decimal, why
>>> not before?
>> Hm, would there be any real use-case
On Fri, Jun 12, 2020 at 2:14 PM Tom Lane wrote:
> Robert Haas writes:
> > BTW, has there been any thought to supporting a negative scale for the
> > numeric data type? If you can cut off digits after the decimal, why
> > not before?
>
> Hm, would there be any real use-case?
Compatibility... appa
Robert Haas writes:
> BTW, has there been any thought to supporting a negative scale for the
> numeric data type? If you can cut off digits after the decimal, why
> not before?
Hm, would there be any real use-case?
An implementation issue is that even in the "long" numeric format,
we cram dscale
> "Tom" == Tom Lane writes:
[...]
Tom> so that a finite value should never map to INT[64]_MIN, making it
Tom> safe to do as you suggest. I agree that distinguishing +Inf from
Tom> NaN is probably more useful than distinguishing it from the very
Tom> largest class of finite values, so wil
On Fri, Jun 12, 2020 at 1:01 PM Tom Lane wrote:
> This does tie into something I have a question about in the patch's
> comments though. As the patch stands, numeric(numeric, integer)
> (that is, the typmod-enforcement function) just lets infinities
> through regardless of the typmod, on the grou
Robert Haas writes:
> On Thu, Jun 11, 2020 at 9:16 PM Tom Lane wrote:
>> We had a discussion recently about how it'd be a good idea to support
>> infinity values in type numeric [1].
> FWIW, I don't particularly like the idea. Back when I was an
> application developer, I remember having to inse
On Thu, Jun 11, 2020 at 9:16 PM Tom Lane wrote:
> We had a discussion recently about how it'd be a good idea to support
> infinity values in type numeric [1].
Only a minority of that discussion was actually on that topic, and I'm
not sure there was a clear consensus in favor of it.
FWIW, I don't
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> +#define NUMERIC_ABBREV_PINF
> NumericAbbrevGetDatum(PG_INT64_MIN)
> Tom> +#define NUMERIC_ABBREV_PINF
> NumericAbbrevGetDatum(PG_INT32_MIN)
> I'd have been more inclined to go with -PG_INT64_MAX / -PG_INT32_MAX
> "Tom" == Tom Lane writes:
Tom> @@ -359,10 +390,14 @@ typedef struct NumericSumAccum
Tom> #define NumericAbbrevGetDatum(X) ((Datum) (X))
Tom> #define DatumGetNumericAbbrev(X) ((int64) (X))
Tom> #define NUMERIC_ABBREV_NAN
NumericAbbrevGetDatum(PG_INT64_MIN)
Tom> +#defi
> "Tom" == Tom Lane writes:
Tom> * I'm only about 50% sure that I understand what the sort
Tom> abbreviation code is doing. A quick look from Peter or some other
Tom> expert would be helpful.
That code was originally mine, so I'll look at it.
--
Andrew (irc:RhodiumToad)
We had a discussion recently about how it'd be a good idea to support
infinity values in type numeric [1]. Here's a draft patch enabling
that, using the idea suggested in that thread of commandeering some
unused bits in the representation of numeric NaNs. AFAICT we've been
careful to ensure those
21 matches
Mail list logo
