Re: Should we document how column DEFAULT expressions work? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Should we document how column DEFAULT expressions work?
Date
Msg-id 2739273.1719845033@sss.pgh.pa.us
Whole thread Raw
In response to Re: Should we document how column DEFAULT expressions work?  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Should we document how column DEFAULT expressions work?
List pgsql-hackers
Peter Eisentraut <peter@eisentraut.org> writes:
> On 01.07.24 01:54, David Rowley wrote:
>> I think there are valid reasons to use the special timestamp input
>> values.  One that I can think of is for use with partition pruning. If
>> you have a time-range partitioned table and want the planner to prune
>> the partitions rather than the executor, you could use
>> 'now'::timestamp in your queries to allow the planner to prune.

> Yeah, but is that a good user interface?  Or is that just something that 
> happens to work now with the pieces that happened to be there, rather 
> than a really designed interface?

That's not a very useful argument to make.  What percentage of the
SQL language as a whole is legacy cruft that we'd do differently if
we could?  I think the answer is depressingly high.  Adding more
special-purpose features to the ones already there doesn't move
that needle in a desirable direction.

I'd be more excited about this discussion if I didn't think that
the chances of removing 'now'::timestamp are exactly zero.  You
can't just delete useful decades-old features, whether there's
a better way or not.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Surround CheckRelation[Oid]LockedByMe() with USE_ASSERT_CHECKING
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: speed up a logical replica setup