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 1sDzao-00GWaO-7E for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jun 2024 04:46:47 +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 1sDzan-008zXb-2T for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jun 2024 04:46:45 +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 1sDzam-008zXT-Ow for pgsql-hackers@lists.postgresql.org; Mon, 03 Jun 2024 04:46:44 +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 1sDzaj-0024qJ-M4 for pgsql-hackers@lists.postgresql.org; Mon, 03 Jun 2024 04:46:44 +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 4534ka0R2416640; Mon, 3 Jun 2024 00:46:36 -0400 From: Tom Lane To: Peter Eisentraut cc: Amit Langote , Alvaro Herrera , pgsql-hackers@lists.postgresql.org Subject: Re: pgsql: Add more SQL/JSON constructor functions In-reply-to: <50a780ab-f1a4-4c5f-b9a1-88a174cf12af@eisentraut.org> References: <202405271313.qkl63gffldmx@alvherre.pgsql> <202405271326.5a5rprki64aw@alvherre.pgsql> <3189.1717001075@sss.pgh.pa.us> <50a780ab-f1a4-4c5f-b9a1-88a174cf12af@eisentraut.org> Comments: In-reply-to Peter Eisentraut message dated "Sun, 02 Jun 2024 23:17:06 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2416638.1717389996.1@sss.pgh.pa.us> Date: Mon, 03 Jun 2024 00:46:36 -0400 Message-ID: <2416639.1717389996@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > On 29.05.24 18:44, Tom Lane wrote: >> Yeah, I too think this is a cast, and truncation is the spec-defined >> behavior for casting to varchar with a specific length limit. > The SQL standard says essentially that the output of json_serialize() is > some string that when parsed back in gives you an equivalent JSON value > as the input. That doesn't seem compatible with truncating the output. Maybe you should take this up with the SQL committee? If you don't like our current behavior, then either you have to say that RETURNING with a length-limited target type is illegal (which is problematic for the spec, since they have no such type) or that the cast behaves like an implicit cast, with errors for overlength input (which I find to be an unintuitive definition for a construct that names the target type explicitly). > If you want output truncation, you can of course use an actual cast. > But it makes sense that the RETURNING clause is separate from that. Are you trying to say that the RETURNING clause's specified type isn't the actual output type? I can't buy that either. Again, if you think our existing behavior isn't right, I think it's a problem for the SQL committee not us. regards, tom lane