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

From James Coleman
Subject Re: Should we document how column DEFAULT expressions work?
Date
Msg-id CAAaqYe9_RE2WximHuYRpyfU-H2G+W--49e_8GDqS-vHLOzPvmg@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>)
Responses Re: Should we document how column DEFAULT expressions work?
Re: Should we document how column DEFAULT expressions work?
List pgsql-hackers
On Tue, Jun 25, 2024 at 4:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> James Coleman <jtc331@gmail.com> writes:
> > It's possible I'm the only one who's been in this situation, but I've
> > multiple times found myself explaining to a user how column DEFAULT
> > expressions work: namely how the quoting on an expression following
> > the keyword DEFAULT controls whether or not the expression is
> > evaluated at the time of the DDL statement or at the time of an
> > insertion.
>
> Uh ... what?  I recall something about that with respect to certain
> features such as nextval(), but you're making it sound like there
> is something generic going on with DEFAULT.

Hmm, I guess I'd never considered anything besides cases like
nextval() and now(), but I see now that now() must also be special
cased (when quoted) since 'date_trunc(day, now())'::timestamp doesn't
work but 'now()'::timestamp does.

So I guess what I'm asking about would be limited to those cases (I
assume there are a few others...but I haven't gone digging through the
source yet).

Regards,
James Coleman



pgsql-hackers by date:

Previous
From: David E. Wheeler
Date:
Subject: Re: RFC: Additional Directory for Extensions
Next
From: Noah Misch
Date:
Subject: Re: IPC::Run accepts bug reports