On 01.07.24 01:54, David Rowley wrote:
On Thu, 27 Jun 2024 at 23:57, Peter Eisentraut <pe...@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.
