Re: Should we document how column DEFAULT expressions work?
От | Tom Lane |
---|---|
Тема | Re: Should we document how column DEFAULT expressions work? |
Дата | |
Msg-id | 1639492.1719445105@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Should we document how column DEFAULT expressions work? (David Rowley <dgrowleyml@gmail.com>) |
Список | 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 по дате отправления: