Re: SQL/JSON features for v15

Поиск
Список
Период
Сортировка
От Nikita Glukhov
Тема Re: SQL/JSON features for v15
Дата
Msg-id 3596205e-ce1e-6959-7559-6ddd67f8294b@postgrespro.ru
обсуждение исходный текст
Ответ на Re: SQL/JSON features for v15  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Ответы Re: SQL/JSON features for v15  (Andrew Dunstan <andrew@dunslane.net>)
Re: SQL/JSON features for v15  (Amit Langote <amitlangote09@gmail.com>)
Список pgsql-hackers


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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Inconsistencies around defining FRONTEND
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Inconsistencies around defining FRONTEND