Re: SQL/JSON features for v15

On 8/26/22 4:36 PM, Andrew Dunstan wrote:
>
> On 2022-08-26 Fr 16:11, Nikita Glukhov wrote:
>>
>> Hi,
>>
>> On 26.08.2022 22:25, Andrew Dunstan wrote:
>>> On 2022-08-24 We 20:05, Nikita Glukhov wrote:
>>>> v8 - is a highly WIP patch, which I failed to finish today.
>>>> Even some test cases fail now, and they simply show unfinished
>>>> things like casts to bytea (they can be simply removed) and missing
>>>> safe input functions.
>>> Thanks for your work, please keep going.
>> I have completed in v9 all the things I previously planned:
>>
>> - Added missing safe I/O and type conversion functions for
>> datetime, float4, varchar, bpchar. This introduces a lot
>> of boilerplate code for returning errors and also maybe
>> adds some overhead.
>>
>> - Added JSON_QUERY coercion to UTF8 bytea using pg_convert_to().
>>
>> - Added immutability checks that were missed with elimination
>> of coercion expressions.
>> Coercions text::datetime, datetime1::datetime2 and even
>> datetime::text for some datetime types are mutable.
>> datetime::text can be made immutable by passing ISO date
>> style into output functions (like in jsonpath).
>>
>> - Disabled non-Const expressions in DEFAULT ON EMPTY in non
>> ERROR ON ERROR case. Non-constant expressions are tried to
>> evaluate into Const directly inside transformExpr().
>> Maybe it would be better to simply remove DEFAULT ON EMPTY.
>
>
> Yes, I think that's what I suggested upthread. I don't think DEFAULT ON
> EMPTY matters that much, and we can revisit it for release 16. If it's
> simpler please do it that way.
>
>
>> It is possible to easily split this patch into several subpatches,
>> I will do it if needed.
>
>
> Thanks, probably a good idea but I will start reviewing what you have
> now. Andres and others please chime in if you can.

Thanks Nikita!

I looked through the tests to see if we would need any doc changes, e.g.
in [1]. I noticed that this hint:

"HINT: Use ERROR ON ERROR clause or try to simplify expression into
constant-like form"

lacks a period on the end, which is convention.

I don't know if the SQL/JSON standard calls out if domains should be
castable, but if it does, we should document in [1] that we are not
currently supporting them as return types, so that we're only supporting
"constant-like" expressions with examples.

Looking forward to hearing other feedback.

Thanks,

Jonathan

[1] https://www.postgresql.org/docs/15/functions-json.html#FUNCTIONS-SQLJSON