Re: Should we document how column DEFAULT expressions work?
| От | David Rowley |
|---|---|
| Тема | Re: Should we document how column DEFAULT expressions work? |
| Дата | |
| Msg-id | CAApHDvogKE8RrHx=qmYfvpD_AiVLX14nLvvSrPbFCXWgiYrKxg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Should we document how column DEFAULT expressions work? ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Ответы |
Re: Should we document how column DEFAULT expressions work?
|
| Список | pgsql-hackers |
On Mon, 1 Jul 2024 at 12:16, David G. Johnston <david.g.johnston@gmail.com> wrote: > > On Sun, Jun 30, 2024 at 4:55 PM David Rowley <dgrowleyml@gmail.com> wrote: >> >> >> I'd like to know what led someone down the path of doing something >> like DEFAULT 'now()'::timestamp in a CREATE TABLE. Could it be a >> faulty migration tool that created these and people copy them thinking >> it's a legitimate syntax? >> > > My thought process on this used to be: Provide a text string of the expression that is then stored within the catalogand eval'd during runtime. If the only thing you are providing is a single literal and not some compound expressionit isn't that obvious that you are supposed to provide an unquoted expression - which feels like it should be immediatelyevaluated - versus something that is a constant. Kinda like dynamic SQL. Thanks for sharing that. Any idea where that thinking came from? Maybe it was born from the fact that nothing complains when you do: 'now()'::timestamp? A quick test evaluation of that with a SELECT statement might trick someone into thinking it'll work. I wonder if there's anything else like this that might help fool people into thinking this is some valid way of getting delayed evaluation. David
В списке pgsql-hackers по дате отправления: