Re: Should we document how column DEFAULT expressions work?

On Tue, Jun 25, 2024 at 10:12 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David Rowley <dgrowleyml(at)gmail(dot)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.

David J.