Re: Should we document how column DEFAULT expressions work?

On 01.07.24 01:54, David Rowley wrote:
> On Thu, 27 Jun 2024 at 23:57, Peter Eisentraut <peter@eisentraut.org> wrote:
>> Maybe we should really be thinking about deprecating these special
>> values and steering users more urgently toward more robust alternatives.
>>
>> Imagine if 'random' were a valid input value for numeric types.
> 
> 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?

Hypothetically, what would need to be done to make this work with now() 
or current_timestamp or something similar?  Do we need a new stability 
level that somehow encompasses this behavior, so that the function call 
can be evaluated at planning time?

> That
> works providing that you never use that in combination with PREPARE
> and never put the query with the WHERE clause inside a VIEW.

And this kind of thing obviously makes this interface even worse.