| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Should we document how column DEFAULT expressions work? |
| Date: | 2024-06-26 23:38:25 |
| Message-ID: | 1639492.1719445105@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Wed, 26 Jun 2024 at 17:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2024-06-26 23:54:01 | Re: Should we document how column DEFAULT expressions work? |
| Previous Message | David Rowley | 2024-06-26 23:19:38 | Re: Should we document how column DEFAULT expressions work? |