Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMFK0-001Jiv-4t for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Jun 2024 23:11:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sMFJy-000rvT-9k for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Jun 2024 23:11:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMFJx-000rvK-WE for pgsql-hackers@lists.postgresql.org; Tue, 25 Jun 2024 23:11:30 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMFJv-003YUb-B3 for pgsql-hackers@postgresql.org; Tue, 25 Jun 2024 23:11:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 45PNBO7U1390100; Tue, 25 Jun 2024 19:11:24 -0400 From: Tom Lane To: James Coleman cc: pgsql-hackers Subject: Re: Should we document how column DEFAULT expressions work? In-reply-to: References: <1362410.1719349169@sss.pgh.pa.us> Comments: In-reply-to James Coleman message dated "Tue, 25 Jun 2024 19:05:04 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1390098.1719357084.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jun 2024 19:11:24 -0400 Message-ID: <1390099.1719357084@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk James Coleman writes: > On Tue, Jun 25, 2024 at 4:59=E2=80=AFPM Tom Lane wro= te: >> 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. Hmm, both of those behaviors are documented, but not in the same place and possibly not anywhere near where you looked for info about DEFAULT. For instance, the Tip at the bottom of section 9.9.5 https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-= DATETIME-CURRENT explains about how 'now'::timestamp isn't what to use in DEFAULT. regards, tom lane