On Tue, Jun 25, 2024 at 10:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <dgrowleyml@gmail.com> writes: > If people don't properly understand these special timestamp input > values, then maybe the documentation in [1] needs to be improved. At > the moment the details are within parentheses. Namely "(In particular, > now and related strings are converted to a specific time value as soon > as they are read.)". Maybe it would be better to be more explicit > there and mention that these are special values that the input > function understands which are translated to actual timestamp values > when the type's input function is called. That could maybe be tied > into the DEFAULT clause documentation to mention that the input > function for constant values is called at DML time rather than DDL > time. That way, we're not adding these (unsustainable) special cases > to the documentation.
This sounds like a reasonable approach to me for the magic-input-values issue. Do we want to do anything about nextval()? I guess if you hold your head at the correct angle, that's also a magic-input-value issue, in the sense that the question is when does regclass input get resolved.
From observations we transform constants into the: " 'value'::type " syntax which then makes it an operator resolved at execution time. For every type except time types the transformation leaves the constant as-is. The special time values are the exception whereby they get evaluated to a specific time during the transformation.
postgres=# create table tser3 (id integer not null default nextval(regclass 'tser2_id_seq'));
CREATE TABLE postgres=# \d tser3 Table "public.tser3" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+----------------------------------- id | integer | | not null | nextval('tser2_id_seq'::regclass)
I cannot figure out how to get "early binding" into the default. I.e., nextval(9000)
Since early binding is similar to the special timestamp behavior I'd say nextval is behaving just as expected - literal transform, no evaluation. We need only document the transforms that also evaluate.
