Thread: Re: Can't figure out how to use now() in default for tsrange column (PG 9.2)

Re: Can't figure out how to use now() in default for tsrange column (PG 9.2)

From
Chris Bartlett
Date:
>Chris Bartlett <c.bartlett@paradise.net.nz> writes:
>>  I'm trying to set [now(), 2049-12-31 00:00:00) as the default for a
>>  tsrange column (Postgres 9.2), but can't figure out how to do it. I'm
>>  either getting syntax errors or now() is being evaluated, so that the
>>  default becomes something like [2012-07-14 14:04:35, 2049-12-31
>>  00:00:00), which is not what I want. Can anyone point me in the right
>>  direction, please?
>
>I think you'd need to use the constructor function, ie
>
>    default tsrange(now(), '2049-12-31 00:00:00')

I had tried the constructor function and hadn't managed to get a
successful result. E.g.

alter table the_table alter column the_column set default
tsrange(now(), '2049-12-31 00:00:00');
-> ERROR:  function tsrange(timestamp with time zone, unknown) does not exist
HINT:  No function matches the given name and argument types. You
might need to add explicit type casts.

Realisation: now() is a timestamp with time zone, but my column is a
timestamp without time zone. So this works:

alter table the_table alter column the_column set default
tsrange(now()::timestamp without time zone, '2049-12-31
00:00:00'::timestamp without time zone);
-> ALTER TABLE

>BTW, that second value looks a whole lot like a poorly thought out
>substitute for 'infinity' ...
>            regards, tom lane


That's certainly an interesting comment and I'm open to suggestions!
The original db has two columns (from_timestamp, to_timestamp). I
don't go for NULL in the to_timestamp column. Alternatively, a
timestamp very, very far in the future can throw off query planners.

Thanks,
Chris

Re: Can't figure out how to use now() in default for tsrange column (PG 9.2)

From
"Kevin Grittner"
Date:
Chris Bartlett <c.bartlett@paradise.net.nz> wrote:

> my column is a timestamp without time zone.

In spite of the fact that this was sort of tangential to you primary
question, I'm a little surprised that nobody responded to this
point.  There are very, very few situations where the semantics of
TIMESTAMP WITHOUT TIME ZONE are really what people want; you should
seriously consider using TIMESTAMP WITH TIME ZONE.  In PostgreSQL
neither one actually stores a time zone; the difference is that WITH
TIME ZONE it represents a particular moment in a continuous stream
of time, while WITHOUT TIME ZONE the value can be interpreted to be
any of various times depending on the time zone of the reader.
WITHOUT TIME ZONE you will see time jump around at daylight saving
time boundaries, and you will tend to have ambiguous times after the
clock has moved backward, where you can't tell what actual moment is
intended.

As you noted, now() is TIMESTAMP WITH TIME ZONE -- it has to be,
because it represents a moment in time.

-Kevin