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
10 matches
Mail list logo
