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