Re: Should we document how column DEFAULT expressions work?

From: Pantelis Theodosiou <ypercube(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, "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-07-06 09:51:20
Message-ID: CAE3TBxzjk2Du==pC=e3GbVW9O8QOKWY4gzq-A7=OKg=AuShbUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 27, 2024 at 1:11 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <dgrowleyml(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Frank Streitzig 2024-07-06 09:57:02 Re: XML test error on Arch Linux
Previous Message Dean Rasheed 2024-07-06 09:34:18 Re: Optimize numeric multiplication for one and two base-NBASE digit multiplicands.