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