Horton

Re: SQL/JSON features for v15

Pavel Stehule <pavel.stehule@gmail.com>

View thread View on postgr.es
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, "Jonathan S. Katz" <jkatz@postgresql.org>, Nikita Glukhov <n.gluhov@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Michael Paquier <michael@paquier.xyz>, John Naylor <john.naylor@enterprisedb.com>, Amit Langote <amitlangote09@gmail.com>
Date: 2022-08-23T19:57:37Z
Lists: pgsql-hackers 
út 23. 8. 2022 v 21:54 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:

> Andres Freund <andres@anarazel.de> writes:
> > On 2022-08-23 13:28:50 -0400, Tom Lane wrote:
> >> I agree with the upthread comments that we only need/want to catch
> >> foreseeable incorrect-input errors, and that the way to make that
> >> happen is to refactor the related type input functions, and that
> >> a lot of the heavy lifting for that has been done already.
>
> > I think it's a good direction to go in. What of the heavy lifting for
> that has
> > been done already? I'd have guessed that the hard part is to add
> different,
> > optional, type input, type coercion signatures, and then converting a
> lot of
> > types to that?
>
> I was assuming that we would only bother to do this for a few core types.
> Of those, at least the datetime types were already done for previous
> JSON-related features.  If we want extensibility, then as Robert said
> there's going to have to be work done to create a common API that type
> input functions can implement, which seems like a pretty heavy lift.
> We could get it done for v16 if we start now, I imagine.
>

+1

Pavel


>                         regards, tom lane
>
>
>

Commits

  1. JSON_TABLE: Add support for NESTED paths and columns

  2. Add basic JSON_TABLE() functionality

  3. Add SQL/JSON query functions

  4. Add soft error handling to some expression nodes

  5. Adjust populate_record_field() to handle errors softly

  6. Refactor code used by jsonpath executor to fetch variables

  7. Add more SQL/JSON constructor functions

  8. SQL/JSON: support the IS JSON predicate

  9. SQL/JSON: add standard JSON constructor functions

  10. Revert SQL/JSON features

  11. Numeric error suppression in jsonpath