Chapman Flack writes:
> On 03/01/19 17:34, Tom Lane wrote:
>> Using custom operator names would work better/more reliably.
> Or a new base type (LIKE float8) rather than a domain?
Yeah, it'd be more work but you would have control over the
coercion rules.
regards, tom la
On 03/01/19 17:34, Tom Lane wrote:
> but I think it'd be fragile to use. (See the "Type Conversion"
> chapter in the manual for the gory details, and note that domains
> get smashed to their base types mighty readily.)
>
> Using custom operator names would work better/more reliably.
Or a new ba
Chapman Flack writes:
> I wanted to try this out a little before assuming it would work,
> and there seems to be no trouble creating a trivial domain over
> float8 (say, CREATE DOMAIN ieeedouble AS float8), and then creating
> operators whose operand types are the domain type.
While you can do th
On Fri, Mar 1, 2019 at 4:51 PM Chapman Flack wrote:
> On 3/1/19 3:49 PM, Matt Pulver wrote:
>
> > In many applications, I would much rather see calculations carried out
> > via IEEE 754 all the way to the end, with nans and infs, which
> > provides much more useful diagnostic information than an
On 3/1/19 3:49 PM, Matt Pulver wrote:
> In many applications, I would much rather see calculations carried out
> via IEEE 754 all the way to the end, with nans and infs, which
> provides much more useful diagnostic information than an exception that
> doesn't return any rows at all. As Andres Freu
On Fri, Mar 1, 2019 at 12:59 PM Andrew Gierth
wrote:
> > "Matt" == Matt Pulver writes:
>
> Matt> ERROR: division by zero
>
> Matt> Question: If Infinity and NaN are supported, then why throw an
> Matt> exception here, instead of returning Infinity?
>
> Spec says so:
>
> 4) The dyadic a
On 3/1/19 2:26 PM, David G. Johnston wrote:
> Upon further reading you are correct - IEEE 754 has chosen to treat n/0
> differently for n=0 and n<>0 cases. I'm sure they have their reasons but
> ... I don't use,
> or have time for the distraction, to understand why such a decision was
> made and
On Friday, March 1, 2019, Chapman Flack wrote:
>
> But if someone wanted to write a user-defined division function or
> operator that would return Inf for (anything > 0) / 0 and for
> (anything < 0) / -0, and -Inf for (anything < 0) / 0 and for
> (anything > 0) / -0, and NaN for (either zero) / (
On 2019-03-01 11:04:04 -0700, David G. Johnston wrote:
> Changing the behavior is not going to happen for any existing data types.
For the overflow case that really sucks, because we're leaving a very
significant amount of performance on the table because we recheck for
overflow in every op. The a
On 3/1/19 1:04 PM, David G. Johnston wrote:
> 1/0 is an illegal operation. We could return NaN for it but the choice of
> throwing an error is just as correct. Returning infinity is strictly
> incorrect.
That differs from my understanding of how the operations are specified
in IEEE 754 (as summ
Hi,
On 2019-03-01 12:46:55 -0500, Matt Pulver wrote:
> PostgreSQL FLOAT appears to support +/-Infinity and NaN per the IEEE 754
> standard, with expressions such as CAST('NaN' AS FLOAT) and CAST('Infinity'
> AS FLOAT) and even supports ordering columns of floats that contain NaN.
>
> However the
On Friday, March 1, 2019, Matt Pulver wrote:
> However the query "SELECT 1.0/0.0;" produces an exception:
>
> ERROR: division by zero
>
>
> Question: If Infinity and NaN are supported, then why throw an exception
> here, instead of returning Infinity? Is it purely for historical reasons,
> or if
> "Matt" == Matt Pulver writes:
Matt> ERROR: division by zero
Matt> Question: If Infinity and NaN are supported, then why throw an
Matt> exception here, instead of returning Infinity?
Spec says so:
4) The dyadic arithmetic operators , ,
, and (+, -, *, and /, respectively) spec
Hello,
PostgreSQL FLOAT appears to support +/-Infinity and NaN per the IEEE 754
standard, with expressions such as CAST('NaN' AS FLOAT) and CAST('Infinity'
AS FLOAT) and even supports ordering columns of floats that contain NaN.
However the query "SELECT 1.0/0.0;" produces an exception:
ERROR:
14 matches
Mail list logo
