Emre Hasegeli writes:
> We can also consider turning the current float to numeric casts to
> explicit as they are causing data loss. I am not sure how much it
> would impact backwards-compatibility. The counter argument is the
> numeric to float casts being IMPLICIT. They are causing data loss
Chapman Flack writes:
> I wonder whether even changing a formerly-implicit cast to explicit
> would be too much of a behavior change for existing code that expects
> the current behavior?
We did exactly that during the 8.3 cycle, and got one heck of a lot of
pushback about it, despite the existen
On 03/09/18 12:05, Emre Hasegeli wrote:
> In this case, I cannot see any other option than adding those as
> separate cast functions. Should we mark this entry as "returned with
> feedback"?
>
> We can also consider turning the current float to numeric casts to
> explicit as they are causing data
>> I wonder if an alternative to making a cast that can't be immutable,
>> because it looks at a GUC, could be to offer a choice of cast
>> functions: if you need the other behavior, create a schema, do a
>> CREATE CAST in it, and put it on your search path ahead of pg_catalog.
>
> Nope, because ca
On Mon, Feb 26, 2018 at 11:29 AM, Tom Lane wrote:
> Chapman Flack writes:
> > The 0002-*.patch is a proof-of-concept patching float4_numeric and
> > float8_numeric in the trivial way (just using FLT_DECIMAL_DIG and
> > DBL_DECIMAL_DIG in place of FLT_DIG and DBL_DIG). It makes the new
> > regres
Chapman Flack writes:
> I wonder if an alternative to making a cast that can't be immutable,
> because it looks at a GUC, could be to offer a choice of cast
> functions: if you need the other behavior, create a schema, do a
> CREATE CAST in it, and put it on your search path ahead of pg_catalog.
On 02/26/2018 01:29 PM, Tom Lane wrote:
> I think there's probably a bigger chance of complaints that
> "casting 1.1::float8 to numeric now produces some weird,
> incorrectly-rounded result" than that we make anyone happier.
Arguably, though, that's a moment that can be used to explain
exactly wh
On Mon, Feb 26, 2018 at 1:29 PM, Tom Lane wrote:
> The bigger question here is whether people actually want this behavioral
> change. I think there's probably a bigger chance of complaints that
> "casting 1.1::float8 to numeric now produces some weird,
> incorrectly-rounded result" than that we m
Chapman Flack writes:
> The 0002-*.patch is a proof-of-concept patching float4_numeric and
> float8_numeric in the trivial way (just using FLT_DECIMAL_DIG and
> DBL_DECIMAL_DIG in place of FLT_DIG and DBL_DIG). It makes the new
> regression test pass. (It will only work under a compiler that has
>
Here are two patches.
The 0001-*.patch simply adds a regression test to numeric.sql that bits
aren't lost casting from float[48] to numeric. Naturally, it fails at this
stage.
The 0002-*.patch is a proof-of-concept patching float4_numeric and
float8_numeric in the trivial way (just using FLT_DECI
Back in
https://www.postgresql.org/message-id/4e384467-f28a-69ce-
75aa-4bc01125a39d%40anastigmatix.net
I got intrigued about casting float values to numeric. Two queries below
(one for float4, one for float8) show what happens for float values with
bits of precision from one up to the limit of th
11 matches
Mail list logo
