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
