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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Joe Conway <mail@joeconway.com>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Error-safe user functions
Date: Fri, 09 Dec 2022 20:28:47 -0500
Message-ID: <1181028.1670635727@sss.pgh.pa.us> (raw)
In-Reply-To: <5aaf7c66-9df9-21a9-1ff4-02c7848def52@dunslane.net>
References: <4009543.1670422833@sss.pgh.pa.us>
	<6acddf68-7cb7-e9e7-a5a7-0abc87b3c55b@dunslane.net>
	<CAKFQuwYdQqQru9tpMpY4JpCEJ8OeN8kwmBG6DY2QyzE+5znA6Q@mail.gmail.com>
	<4111458.1670444176@sss.pgh.pa.us>
	<3211.1670452341@sss.pgh.pa.us>
	<20221207233518.sudtaxn6omtvpzvr@awork3.anarazel.de>
	<186288.1670517119@sss.pgh.pa.us>
	<CA+TgmoZOhQ8FfWH9_r58tLtb=AwBn=7ugO2PHh6moR8jhYviUA@mail.gmail.com>
	<20221208215836.3naznqmal2m32hzc@awork3.anarazel.de>
	<512551.1670540229@sss.pgh.pa.us>
	<20221209023351.l362yejerfoq3lfp@awork3.anarazel.de>
	<633426.1670554790@sss.pgh.pa.us>
	<01ff2051-806d-af2f-4f9e-793f7ba9a3f8@dunslane.net>
	<778369.1670598993@sss.pgh.pa.us>
	<5aaf7c66-9df9-21a9-1ff4-02c7848def52@dunslane.net>

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2022-12-09 Fr 10:16, Tom Lane wrote:
>> As I said, I'll take a look at the datetime area.  Do we
>> have any volunteers for other input functions?

> I am currently looking at the json types. I think that will be enough to
> let us rework the sql/json patches as discussed a couple of months ago.

Cool.  I've finished up what I wanted to do with the datetime code.

It occurred to me that we're going to have a bit of a problem
with domain_in.  We can certainly make it pass back any soft
errors from the underlying type's input function, and we can
make it return a soft error if a domain constraint evaluates
to false.  However, what happens if some function in a check
constraint throws an error?  Our only hope of trapping that,
given that it's a general user-defined expression, would be
a subtransaction.  Which is exactly what we don't want here.

I think though that it might be okay to just define this as
Not Our Problem.  Although we don't seem to try to enforce it,
non-immutable domain check constraints are strongly deprecated
(the CREATE DOMAIN man page says that we assume immutability).
And not throwing errors is something that we usually consider
should ride along with immutability.  So I think it might be
okay to say "if you want soft error treatment for a domain,
make sure its check constraints don't throw errors".

Thoughts?

			regards, tom lane





view thread (175+ messages)  latest in thread

Message-ID: <1181028.1670635727@sss.pgh.pa.us>
Permalink:  ../1181028.1670635727@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1181028.1670635727@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, andrew@dunslane.net, andres@anarazel.de, aekorotkov@gmail.com, robertmhaas@gmail.com, david.g.johnston@gmail.com, corey.huinker@gmail.com, alvherre@alvh.no-ip.org, mail@joeconway.com, n.gluhov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
  Subject: Re: Error-safe user functions
  In-Reply-To: <1181028.1670635727@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