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 1sMcjI-003S2t-Tc for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jun 2024 00:11:12 +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 1sMcjG-007Azc-DH for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jun 2024 00:11:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMcjG-007AzT-3U for pgsql-hackers@lists.postgresql.org; Thu, 27 Jun 2024 00:11:10 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMcjC-003Itc-I4 for pgsql-hackers@postgresql.org; Thu, 27 Jun 2024 00:11:09 +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 45R0B3RK1642804; Wed, 26 Jun 2024 20:11:03 -0400 From: Tom Lane To: David Rowley cc: "David G. Johnston" , James Coleman , pgsql-hackers Subject: Re: Should we document how column DEFAULT expressions work? In-reply-to: References: <1362410.1719349169@sss.pgh.pa.us> <1390099.1719357084@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Thu, 27 Jun 2024 11:54:01 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1642802.1719447063.1@sss.pgh.pa.us> Date: Wed, 26 Jun 2024 20:11:03 -0400 Message-ID: <1642803.1719447063@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley 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. regards, tom lane