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

From Pantelis Theodosiou
Subject Re: Should we document how column DEFAULT expressions work?
Date
Msg-id CAE3TBxzjk2Du==pC=e3GbVW9O8QOKWY4gzq-A7=OKg=AuShbUw@mail.gmail.com
Whole thread Raw
In response to Re: Should we document how column DEFAULT expressions work?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jun 27, 2024 at 1:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > Maybe I'm slow on the uptake, but I've yet to see anything here where
> > time literals act in a special way DEFAULT constraints. This is why I
> > couldn't understand why we should be adding documentation about this
> > under CREATE TABLE.
>
> It's not that the parsing rules are any different: it's that in
> ordinary DML queries, it seldom matters very much whether a
> subexpression is evaluated at parse time versus run time.
> In CREATE TABLE that difference is very in-your-face, so people
> who haven't understood the rules clearly can get burnt.
>
> However, there are certainly other places where it matters,
> such as queries in plpgsql functions.  So I understand your
> reluctance to go on about it in CREATE TABLE.  At the same
> time, I see where David J. is coming from.
>
> Maybe we could have a discussion of this in some single spot,
> and link to it from CREATE TABLE and other relevant places?
> ISTR there is something about it in the plpgsql doco already.
>

+1 to this idea.



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.
Next
From: Frank Streitzig
Date:
Subject: Re: XML test error on Arch Linux