Horton

Re: SQL/JSON features for v15

Nikita Glukhov <n.gluhov@postgrespro.ru>

View thread View on postgr.es
From: Nikita Glukhov <n.gluhov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, "Jonathan S. Katz" <jkatz@postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Amit Langote <amitlangote09@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>, John Naylor <john.naylor@enterprisedb.com>
Date: 2022-08-31T20:39:31Z
Lists: pgsql-hackers

Attachments

On 31.08.2022 20:14, Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com>  writes:
>> On Wed, Aug 31, 2022 at 1:06 PM Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>>> The currently proposed patchset hacks up a relatively small number
>>> of core datatypes to be able to do that.  But it's just a hack
>>> and there's no prospect of extension types being able to join
>>> in the fun.  I think where we need to start, for v16, is making
>>> an API design that will let any datatype have this functionality.
>>>
>>> (I don't say that we'd convert every datatype to do so right away;
>>> in the long run we should, but I'm content to start with just the
>>> same core types touched here.)  Beside the JSON stuff, there is
>>> another even more pressing application for such behavior, namely
>>> the often-requested COPY functionality to be able to shunt bad data
>>> off somewhere without losing the entire transfer.  In the COPY case
>>> I think we'd want to be able to capture the error message that
>>> would have been issued, which means the current patches are not
>>> at all appropriate as a basis for that API design: they're just
>>> returning a bool without any details.
>>>
>> I would be in favor of making more of an effort than just a few token
>> data types. The initial patch could just touch a few, but once the
>> infrastructure is in place we should really make a sweep through the
>> tree and tidy up.
> Sure, but my point is that we can do that in a time-extended fashion
> rather than having a flag day where everything must be updated.
> The initial patch just needs to update a few types as proof of concept.
>
And here is a quick POC patch with an example for COPY and float4:

=# CREATE TABLE test (i int, f float4);
CREATE TABLE

=# COPY test (f) FROM stdin WITH (null_on_error (f));
1
err
2
\.

COPY 3

=# SELECT f FROM test;
  f
---
  1
   
  2
(3 rows)

=# COPY test (i) FROM stdin WITH (null_on_error (i));
ERROR:  input function for datatype "integer" does not support error handling



PG_RETURN_ERROR() is a reincarnation of ereport_safe() macro for returning
ErrorData, which was present in older versions (~v18) of SQL/JSON patches.
Later it was replaced with `bool *have_error` and less magical
`if (have_error) ... else ereport(...)`.


Obviously, this needs a separate thread.

-- 
Nikita Glukhov
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company

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