Re: SQL/JSON features for v15

[Jonathan S. Katz]

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!





lacks a period on the end, which is convention.



Looking forward to hearing other feedback.

Thanks,

Jonathan

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

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" 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.

OpenPGP_signature
Description: OpenPGP digital signature