From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Should we document how column DEFAULT expressions work? |
Date: | 2024-07-01 14:43:53 |
Message-ID: | 2739273.1719845033@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2024-07-01 14:52:46 | RE: speed up a logical replica setup |
Previous Message | Bertrand Drouvot | 2024-07-01 14:38:44 | Re: Surround CheckRelation[Oid]LockedByMe() with USE_ASSERT_CHECKING |