Re: Should we document how column DEFAULT expressions work?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, 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-10-17 00:18:08
Message-ID: 503444.1729124288@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Does anyone like this patch? I changed now()::timestamptz to
> now::timestamptz.

No, because you clearly didn't bother to test it:

regression=# select now::timestamptz;
ERROR: column "now" does not exist
LINE 1: select now::timestamptz;
^

Also "a string that returns a volatile result once cast to a data
type" is pretty meaningless to my eyes, not least because the real
problem is that the construct is *not* volatile, but gets folded to
a constant at CREATE TABLE time.

The distinction we want to draw is that 'now'::timestamptz is a
parse-time constant and so is not equivalent to the function call
now() (which already produces timestamptz, so no need for a cast).
This is already covered at the end of section 9.9.5 Current Date/Time,
although I have no objection to repeating it in some form in the
CREATE TABLE docs.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shinya Kato 2024-10-17 00:32:41 Re: Set AUTOCOMMIT to on in script output by pg_dump
Previous Message Andy Fan 2024-10-17 00:05:41 Re: Considering fractional paths in Append node