Re: SQL/JSON features for v15 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: SQL/JSON features for v15
Date
Msg-id CA+TgmobX2330ByUrrSo1SbcoRPYBbZ1bp3h54hLsxsd1AeBocQ@mail.gmail.com
Whole thread Raw
In response to Re: SQL/JSON features for v15  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SQL/JSON features for v15
List pgsql-hackers
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.

This would be really nice to have.

> (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.)

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.

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

Fully agreed.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SQL/JSON features for v15
Next
From: Tom Lane
Date:
Subject: Re: SQL/JSON features for v15