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

From David Rowley
Subject Re: Should we document how column DEFAULT expressions work?
Date
Msg-id CAApHDvogKE8RrHx=qmYfvpD_AiVLX14nLvvSrPbFCXWgiYrKxg@mail.gmail.com
Whole thread Raw
In response to Re: Should we document how column DEFAULT expressions work?  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Should we document how column DEFAULT expressions work?
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: PostgreSQL does not compile on macOS SDK 15.0
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] Add ACL (Access Control List) acronym