pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Jonathan S. Katz <jkatz@postgresql.org>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: John Naylor <john.naylor@enterprisedb.com>
Cc: Amit Langote <amitlangote09@gmail.com>
Subject: Re: SQL/JSON features for v15
Date: Tue, 23 Aug 2022 13:28:50 -0400
Message-ID: <718874.1661275730@sss.pgh.pa.us> (raw)
In-Reply-To: <20220823172350.djc7u76hdgyh3v4c@awork3.anarazel.de>
References: <20220815223853.itrlpqgpqheg6r6a@awork3.anarazel.de>
	<225d341b-f310-eed0-ceff-b8ec61669d9f@postgrespro.ru>
	<20220816021425.5sa6gx67zmpou3bc@awork3.anarazel.de>
	<8d0ffc54-469a-ffab-68a3-8b547e24a08d@postgresql.org>
	<7d83684b-7932-9f29-400b-0beedfafcdd4@postgrespro.ru>
	<69022273-e7e3-6d1a-10f8-d1b4740e4b97@postgresql.org>
	<92cab50c-152b-84fc-fd49-12b936113a3d@postgresql.org>
	<CA+TgmoaAZq6rRdVA65PBXBKs=jUHhf42Jf78kBLOaX3c6J7MfQ@mail.gmail.com>
	<20220823155511.ffyntlyjl6wrgljv@awork3.anarazel.de>
	<CA+TgmoZ9E2VoYNFJjw4G0E=+0E+Qs8d1MKuELd9ywaVSW67LQQ@mail.gmail.com>
	<20220823172350.djc7u76hdgyh3v4c@awork3.anarazel.de>

Andres Freund <andres@anarazel.de> writes:
> On 2022-08-23 12:26:55 -0400, Robert Haas wrote:
>> 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.

> The code as is handles this to some degree. Only ERRCODE_DATA_EXCEPTION,
> ERRCODE_INTEGRITY_CONSTRAINT_VIOLATION are caught, the rest is immediately
> rethrown.

That's still a lot of territory, considering how nonspecific most
SQLSTATEs are.  Even if you can prove that only the intended cases
are caught today, somebody could inadvertently break it next week
by using one of those codes somewhere else.

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.

			regards, tom lane





view thread (95+ messages)  latest in thread

Message-ID: <718874.1661275730@sss.pgh.pa.us>
Permalink:  ../718874.1661275730@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/718874.1661275730@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, robertmhaas@gmail.com, jkatz@postgresql.org, n.gluhov@postgrespro.ru, pgsql-hackers@lists.postgresql.org, andrew@dunslane.net, michael@paquier.xyz, john.naylor@enterprisedb.com, amitlangote09@gmail.com
  Subject: Re: SQL/JSON features for v15
  In-Reply-To: <718874.1661275730@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox