Isaac Morland writes:
> On Mon, 17 Dec 2018 at 18:00, Tom Lane wrote:
>> tl;dr: we should model it after the behavior of IEEE float infinities,
>> except we'll want to throw errors where those produce NaNs.
> Would it be OK to return NULL for ∞ - ∞?
IMO, no. The only thing worse than inventing
On Mon, 17 Dec 2018 at 18:00, Tom Lane wrote:
> > so I was thinking that
> > postgres=# select 'infinity'::timestamp - 'infinity'::timestamp;
> > would be zero rather than an error, for least surprise.
>
> Wrong. This case needs to be undefined, because "infinity"
> isn't a specific value. Tha
Hi,
On 2018-12-15 11:34:10 -0800, Andres Freund wrote:
> [1] We should optimize the computation using pg_add_s{32,64}_overflow,
> the generated code after that change is *substantially* better (as
> well as the original code much shorter, and correct). And consider,
> as mentioned fur
Simon Riggs writes:
> I would like to represent 'infinity' as interval->months = INT_MAX
Per the discussion upthread, what we need when creating an
infinite value is to set
month = INT32_MAX, day = INT32_MAX, time = INT64_MAX (for +Infinity)
month = INT32_MIN, day = INT32_MIN, time = INT64_MIN (f
On 12/17/18 5:37 PM, Simon Riggs wrote:
> postgres=# select 'infinity'::timestamp = 'infinity'::timestamp;
> ?column?
> --
> t
I'm not persuaded that's a good idea, and would prefer to see an
is_infinite() predicate, and an = operator that complains. But if
the above is current behavior,
On Mon, 17 Dec 2018 at 03:48, Tom Lane wrote:
> The positive argument for adding infinity to interval is that
> we define operations such as timestamp minus timestamp as
> yielding interval. That's why this has to fail right now:
>
> regression=# select timestamp 'infinity' - timestamp 'now';
>
On Sun, 16 Dec 2018 at 22:27, Robert Haas wrote:
> Simon's argument for adding this is that we support 'infinity' for
> timestamp, but is that a good argument for making 'interval' do it,
> given that there are many other types like date for which we don't
> support it?
>
postgres=> select 'inf
Robert Haas writes:
> Simon's argument for adding this is that we support 'infinity' for
> timestamp, but is that a good argument for making 'interval' do it,
> given that there are many other types like date for which we don't
> support it?
My feeling is that date is to timestamp as integer is t
On Sat, Dec 15, 2018 at 3:02 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2018-12-15 14:43:49 -0500, Tom Lane wrote:
> >> Note that timestamp_lt etc don't actually need any special case for
> >> infinity, and we could hope that the infinity representation for interval
> >> makes it possible
Andres Freund writes:
> On 2018-12-15 14:43:49 -0500, Tom Lane wrote:
>> Note that timestamp_lt etc don't actually need any special case for
>> infinity, and we could hope that the infinity representation for interval
>> makes it possible to likewise not special-case it in interval comparisons.
>>
Hi,
On 2018-12-15 14:43:49 -0500, Tom Lane wrote:
> Note that timestamp_lt etc don't actually need any special case for
> infinity, and we could hope that the infinity representation for interval
> makes it possible to likewise not special-case it in interval comparisons.
> But I think it's silly
Andres Freund writes:
> On 2018-12-15 09:44:50 -0500, Tom Lane wrote:
>> Yes. The performance argument has some merit for cases like int4 and
>> float8, where the "useful work" might be as small as one machine
>> instruction. But timestamp and interval operations are, for the most
>> part, prett
Hi,
On 2018-12-15 09:44:50 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 14 Dec 2018 at 22:24, Robert Haas wrote:
> >> So essentially I think supporting special values like infinity boils
> >> down to trading away some small amount of performance -- more likely
> >> to be noticeable w
Simon Riggs writes:
> On Fri, 14 Dec 2018 at 22:24, Robert Haas wrote:
>> So essentially I think supporting special values like infinity boils
>> down to trading away some small amount of performance -- more likely
>> to be noticeable with JIT -- for some amount of possible programmer
>> convenie
On Fri, 14 Dec 2018 at 22:24, Robert Haas wrote:
> So essentially I think supporting special values like infinity boils
> down to trading away some small amount of performance -- more likely
> to be noticeable with JIT -- for some amount of possible programmer
> convenience. Some people may thi
On Fri, Dec 14, 2018 at 9:11 PM Tom Lane wrote:
> Isaac Morland writes:
> > I would be interested if you have an example where the ability of
> > date/timestamp values to be infinite adds special case coding.
>
> I think Robert is talking about the implementation functions for
> timestamp-related
Isaac Morland writes:
> I would be interested if you have an example where the ability of
> date/timestamp values to be infinite adds special case coding.
I think Robert is talking about the implementation functions for
timestamp-related operations, which typically do have to special-case
infinit
On Fri, 14 Dec 2018 at 15:16, Robert Haas wrote:
> Why? I consider it somewhat of a wart that timestamps allow infinity
> - it adds special case coding all over the place. Allowing intervals
> to be infinite as well seems like it'll just create more special cases
> without really solving anyth
On Thu, Dec 13, 2018 at 9:42 AM Simon Riggs wrote:
> At present we have a timestamp of 'infinity' and infinite ranges, but no
> infinite interval
>
> SELECT 'infinity'::timestamp;
> works
>
> SELECT 'infinity'::interval;
> ERROR: invalid input syntax for type interval: "infinity"
>
> Seems a str
Chapman Flack writes:
> On 12/13/18 04:41, Simon Riggs wrote:
>> [ we should allow this: ]
>> SELECT 'infinity'::interval;
>> ERROR: invalid input syntax for type interval: "infinity"
> ... and if that is made to work, perhaps then arithmetic should be
> updated as well,
That wouldn't be option
On 12/13/18 04:41, Simon Riggs wrote:
> SELECT 'infinity'::timestamp;
> works
>
> SELECT 'infinity'::interval;
> ERROR: invalid input syntax for type interval: "infinity"
... and if that is made to work, perhaps then arithmetic should be
updated as well, with this producing an infinite interval
21 matches
Mail list logo
