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
Re: SQL/JSON features for v15 |
Список | 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 will make time although probably Nikita and/or Amit would be quickerI saw Andrew suggest that the controversial parts of the patchset may beIt's an interesting suggestion. Do people have the cycles available
severable from some of the new functionality, so I would like to see
that proposal and if it is enough to overcome concerns.
to make it happen in the next few days?
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 по дате отправления: