Horton

Re: SQL/JSON features for v15

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>, Nikita Glukhov <n.gluhov@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, John Naylor <john.naylor@enterprisedb.com>, Amit Langote <amitlangote09@gmail.com>
Date: 2022-08-23T16:26:55Z
Lists: pgsql-hackers 
On Tue, Aug 23, 2022 at 11:55 AM Andres Freund <andres@anarazel.de> wrote:
> I don't think that's quite realistic - that's the input/output functions for
> all types, basically.  I'd be somewhat content if we'd a small list of very
> common coercion paths we knew wouldn't error out, leaving things like OOM
> aside. Even just knowing that for ->text conversions would be a huge deal in
> the context of this patch.  One problem here is that the whole type coercion
> infrastructure doesn't make it easy to know what "happened inside" atm, one
> has to reconstruct it from the emitted expressions, where there can be
> multiple layers of things to poke through.

But that's exactly what I'm complaining about. Catching an error that
unwound a bunch of stack frames where complicated things are happening
is fraught with peril. There's probably a bunch of errors that could
be thrown from somewhere in that code - out of memory being a great
example - that should not be caught. What you (probably) want is to
know whether one specific error happened or not, and catch only that
one. And the error machinery isn't designed for that. It's not
designed to let you catch specific errors for specific call sites, and
it's also not designed to be particularly efficient if lots of errors
need to be caught over and over again. If you decide to ignore all
that and do it anyway, you'll end up with, at best, code that is
complicated, hard to maintain, and probably slow when a lot of errors
are trapped, and at worst, code that is fragile or outright buggy.

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

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