Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQbSQ-000516-Td for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Aug 2022 21:29:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oQbSO-00010v-J9 for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Aug 2022 21:29:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQbSO-00010l-1E for pgsql-hackers@lists.postgresql.org; Tue, 23 Aug 2022 21:29:08 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oQbSK-0001KM-Lz for pgsql-hackers@lists.postgresql.org; Tue, 23 Aug 2022 21:29:06 +0000 Received: from [192.168.8.199] (unknown [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 3C58C21C3093; Wed, 24 Aug 2022 00:29:00 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1661290141; bh=X16EQHa2eBa6PL1arILV5zag3SX4OKOU86IErvzX7e4=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=RP6ldM5zhYvIZ0c//G+kFHbz6I63/YjN+fiKUp/NHIrRYKualP3al/mvb0e5B5/8a 9pqqm+mmovJ3CKu3Z9a+5l96zfSZ/zby4byVNgsmcn3zdUKtPQa74BIAbblt1MWmRG 9HayqqIDuVtyphkSmF/2V4h3v634tqkQkHPop9Xk= Content-Type: multipart/alternative; boundary="------------VWFw0eFjRt7c6MC0eOFep2mc" Message-ID: <3596205e-ce1e-6959-7559-6ddd67f8294b@postgrespro.ru> Date: Wed, 24 Aug 2022 00:29:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: SQL/JSON features for v15 Content-Language: en-US To: "Jonathan S. Katz" , Andrew Dunstan , Tom Lane Cc: Robert Haas , Andres Freund , PostgreSQL Hackers , Michael Paquier , John Naylor , Amit Langote References: <20220815223853.itrlpqgpqheg6r6a@awork3.anarazel.de> <225d341b-f310-eed0-ceff-b8ec61669d9f@postgrespro.ru> <20220816021425.5sa6gx67zmpou3bc@awork3.anarazel.de> <8d0ffc54-469a-ffab-68a3-8b547e24a08d@postgresql.org> <7d83684b-7932-9f29-400b-0beedfafcdd4@postgrespro.ru> <69022273-e7e3-6d1a-10f8-d1b4740e4b97@postgresql.org> <92cab50c-152b-84fc-fd49-12b936113a3d@postgresql.org> <692364.1661267311@sss.pgh.pa.us> <35468585-e18f-3be6-a228-4ec478f796ac@postgresql.org> <716936.1661275451@sss.pgh.pa.us> From: Nikita Glukhov In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------VWFw0eFjRt7c6MC0eOFep2mc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 23.08.2022 22:31, Jonathan S. Katz wrote: > On 8/23/22 2:10 PM, Andrew Dunstan wrote: >> >> On 2022-08-23 Tu 13:24, Tom Lane wrote: >>> "Jonathan S. Katz" writes: >>>> I saw Andrew suggest that the controversial parts of the patchset >>>> may be >>>> severable from some of the new functionality, so I would like to see >>>> that proposal and if it is enough to overcome concerns. >>> It's an interesting suggestion.  Do people have the cycles available >>> to make it happen in the next few days? >>> >> I will make time although probably Nikita and/or Amit would be quicker >> than I would be. > > If you all can, you have my +1 to try it and see what folks think. I am ready to start hacking now, but it's already night in Moscow, so any result will be only tomorrow. Here is my plan: 0. Take my last v7-0001 patch as a base. It already contains refactoring of JsonCoercion code. (Fix 0002 is not needed anymore, because it is for json[b] domains, which simply will not be supported.) 1. Replace JSON_COERCION_VIA_EXPR in JsonCoercion with new JsonCoercionType(s) for hardcoded coercions. 2. Disable all non-JSON-compatible output types in coerceJsonFuncExpr(). 3. Add missing safe type input functions for integers, numerics, and maybe others. 4. Implement hardcoded coercions using these functions in ExecEvalJsonExprCoercion(). 5. Try to allow only constants (and also maybe column/parameter references) in JSON_VALUE's DEFAULT expressions. This should be enough for the most of practical cases. JSON_QUERY even does not have DEFAULT expressions -- it has only EMPTY ARRAY and EMPTY OBJECT, which can be treated as simple JSON constants. But it is possible to allow all other expressions in ERROR ON ERROR case, and I don't know if it will be consistent enough to allow some expressions in one case and deny in other. And there is another problem: expressions can be only checked for Const-ness only after expression simplification. AFAIU, at the parsing stage they look like 'string'::type. So, it's unclear if it is correct to check expressions in ExecInitExpr(). 6. Remove subtransactions. -- Nikita Glukhov Postgres Professional:http://www.postgrespro.com The Russian Postgres Company --------------VWFw0eFjRt7c6MC0eOFep2mc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 23.08.2022 22:31, Jonathan S. Katz wrote:
On 8/23/22 2:10 PM, Andrew Dunstan wrote:

On 2022-08-23 Tu 13:24, Tom Lane wrote:
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
I saw Andrew suggest that the controversial parts of the patchset may be
severable from some of the new functionality, so I would like to see
that proposal and if it is enough to overcome concerns.
It's an interesting suggestion.  Do people have the cycles available
to make it happen in the next few days?

I will make time although probably Nikita and/or Amit would be quicker
than I would be.

If you all can, you have my +1 to try it and see what folks think. 
I am ready to start hacking now, but it's already night in Moscow, so
any result will be only tomorrow.

Here is my plan:

0. Take my last v7-0001 patch as a base.  It already contains refactoring 
of JsonCoercion code.  (Fix 0002 is not needed anymore, because it is for  
json[b] domains, which simply will not be supported.)

1. Replace JSON_COERCION_VIA_EXPR in JsonCoercion with new
JsonCoercionType(s) for hardcoded coercions.

2. Disable all non-JSON-compatible output types in coerceJsonFuncExpr().

3. Add missing safe type input functions for integers, numerics, and
maybe others.

4. Implement hardcoded coercions using these functions in
ExecEvalJsonExprCoercion().

5. Try to allow only constants (and also maybe column/parameter
references) in JSON_VALUE's DEFAULT expressions.  This should be enough
for the most of practical cases.  JSON_QUERY even does not have DEFAULT
expressions -- it has only EMPTY ARRAY and EMPTY OBJECT, which can be
treated as simple JSON constants.  

But it is possible to allow all other expressions in ERROR ON ERROR 
case, and I don't know if it will be consistent enough to allow some 
expressions in one case and deny in other.  

And there is another problem: expressions can be only checked for 
Const-ness only after expression simplification.  AFAIU, at the
parsing stage they look like 'string'::type.  So, it's unclear if it 
is correct to check expressions in ExecInitExpr().

6. Remove subtransactions.

-- 
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--------------VWFw0eFjRt7c6MC0eOFep2mc--