public inbox for [email protected]
help / color / mirror / Atom feedFrom: David G. Johnston <[email protected]>
To: Tom Lane <[email protected]>
Cc: David Rowley <[email protected]>
Cc: James Coleman <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Should we document how column DEFAULT expressions work?
Date: Tue, 25 Jun 2024 23:00:11 -0700
Message-ID: <CAKFQuwYTbJUWDH62677qWjdbDcD1=LKj8XDDcPPjsegtRS_s-Q@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAAaqYe-wQPbchCUE7pocPNEQ3PMY8a98Txmxc7q0+FvXtk1vvg@mail.gmail.com>
<[email protected]>
<CAAaqYe9_RE2WximHuYRpyfU-H2G+W--49e_8GDqS-vHLOzPvmg@mail.gmail.com>
<[email protected]>
<CAKFQuwZkgm0yqHhf05thqu1gzUK__gXBL5tyBuFvKoOe7Dd6=A@mail.gmail.com>
<CAApHDvoiHYxM2VQYZeiF7JAdP7Y0JxEr86NZpUjoZ9AA4cpzYw@mail.gmail.com>
<[email protected]>
On Tue, Jun 25, 2024 at 10:12 PM Tom Lane <[email protected]> wrote:
> David Rowley <[email protected]> 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.
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Should we document how column DEFAULT expressions work?
In-Reply-To: <CAKFQuwYTbJUWDH62677qWjdbDcD1=LKj8XDDcPPjsegtRS_s-Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox