From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: "David G. Johnston" <david.g.johnston@gmail.com>,
        James Coleman <jtc331@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Should we document how column DEFAULT expressions work?
In-reply-to: <CAApHDvo4z0pU81cfVZTTqWk28oT3rgswtV2nKzSHwDQ=P5aZ=w@mail.gmail.com>
References: <CAAaqYe-wQPbchCUE7pocPNEQ3PMY8a98Txmxc7q0+FvXtk1vvg@mail.gmail.com> <1362410.1719349169@sss.pgh.pa.us> <CAAaqYe9_RE2WximHuYRpyfU-H2G+W--49e_8GDqS-vHLOzPvmg@mail.gmail.com> <1390099.1719357084@sss.pgh.pa.us> <CAKFQuwZkgm0yqHhf05thqu1gzUK__gXBL5tyBuFvKoOe7Dd6=A@mail.gmail.com> <CAApHDvoiHYxM2VQYZeiF7JAdP7Y0JxEr86NZpUjoZ9AA4cpzYw@mail.gmail.com> <1437009.1719378777@sss.pgh.pa.us> <CAApHDvo4z0pU81cfVZTTqWk28oT3rgswtV2nKzSHwDQ=P5aZ=w@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Thu, 27 Jun 2024 11:19:38 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1639491.1719445105.1@sss.pgh.pa.us>
Date: Wed, 26 Jun 2024 19:38:25 -0400
Message-ID: <1639492.1719445105@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1639492.1719445105%40sss.pgh.pa.us>
Precedence: bulk

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