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. That works providing that you never use that in combination with PREPARE and never put the query with the WHERE clause inside a VIEW. I don't have any other good examples, but I suppose that if someone needed to capture the time some statement was executed and record that somewhere, sort of like the __DATE__ and __TIME__ macros in C. Perhaps that's useful to record the last time some DDL script was executed. I'd like to know what led someone down the path of doing something like DEFAULT 'now()'::timestamp in a CREATE TABLE. Could it be a faulty migration tool that created these and people copy them thinking it's a legitimate syntax? David
