Re: Should we document how column DEFAULT expressions work? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Should we document how column DEFAULT expressions work?
Date
Msg-id 1639492.1719445105@sss.pgh.pa.us
Whole thread Raw
In response to Re: Should we document how column DEFAULT expressions work?  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 26 Jun 2024 at 17:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> I think I'm not understanding what's special about that.  Aren't
> 'now'::timestamp and 'seq_name'::regclass are just casts that are
> evaluated during parse time in transformExpr()?

Right.  But there is an example in the manual explaining how
these two things act differently:

    'seq_name'::regclass
    'seq_name'::text::regclass

The latter produces a constant of type text with a run-time
cast to regclass (and hence a run-time pg_class lookup).
IIRC, we document that mainly because the latter provides a way
to duplicate nextval()'s old behavior of run-time lookup.

Now that I think about it, there's a very parallel difference in
the behavior of

    'now'::timestamp
    'now'::text::timestamp

but I doubt that that example is shown anywhere.

            regards, tom lane



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Should we document how column DEFAULT expressions work?
Next
From: David Rowley
Date:
Subject: Re: Should we document how column DEFAULT expressions work?