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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amul Sul <sulamul@gmail.com>
Cc: 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: Wed, 14 Dec 2022 18:24:18 -0500
Message-ID: <3038346.1671060258@sss.pgh.pa.us> (raw)
In-Reply-To: <2687377.1671033604@sss.pgh.pa.us>
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>
	<3bac9841-fe07-713d-fa42-606c225567d6@dunslane.net>
	<1436686.1670701118@sss.pgh.pa.us>
	<2b1e7d56-6f37-bad9-9702-053ab55ecf60@dunslane.net>
	<1805344.1670779451@sss.pgh.pa.us>
	<b54e97be-7316-2cab-6969-bfac6ec88ca6@dunslane.net>
	<1863335.1670783397@sss.pgh.pa.us>
	<CAAJ_b951-kZ=FzWpU31A_Lb! ! j6foJmy852T3YeCT6sAqRbqLPWQ@mail.gmail.com>
	<CAAJ_b97KeDWUdpTKGOaFYPv0OicjOu6EW+QYWj-Ywrgj_aEy1g@mail.gmail.com>
	<2687377.1671033604@sss.pgh.pa.us>

I wrote:
> Amul Sul <sulamul@gmail.com> writes:
>> Attaching a complete set of the patches changing function till this
>> except bpcharin, byteain jsonpath_in that Andrew is planning to look
>> in. I have skipped reg* functions.

> I'll take a look at these shortly, unless Andrew is already on it.

I've gone through these now and revised/pushed most of them.

I do not think that we need to touch any unimplemented I/O functions.
They can just as well be unimplemented for soft-error cases too;
I can't see any use-case where it could be useful to have them not
complain.  So I discarded

v1-0004-Change-brin_bloom_summary_in-to-allow-non-throw-e.patch
v1-0005-Change-brin_minmax_multi_summary_in-to-allow-non-.patch
v1-0009-Change-gtsvectorin-to-allow-non-throw-error-repor.patch
v1-0018-Change-pg_mcv_list_in-to-allow-non-throw-error-re.patch
v1-0019-Change-pg_ndistinct_in-to-allow-non-throw-error-r.patch

As for the rest, some were closer to being committable than others.
You need to be more careful about handling error cases in subroutines:
you can't just ereturn from a subroutine and figure you're done,
because the caller will keep plugging along if you don't do something
to teach it not to.  What that would often lead to is the caller
finding what it thinks is a new error condition, and overwriting the
original message with something that's much less on-point.  This is
comparable to cascading errors from a compiler: anybody who's dealt
with those knows that errors after the first one are often just noise.
So we have to be careful to quit after we log the first error.

Also, I ended up ripping out the changes in line_construct, because
as soon as I tried to test them I tripped over the fact that lseg_sl
was still throwing hard errors, before we ever get to line_construct.
Perhaps it is worth fixing all that but I have to deem it very low
priority, because the two-input-points formulation isn't the mainstream
code path.  (I kind of wonder too if there isn't a better, more
numerically robust conversion method ...)  In any case I'm pretty sure
those changes in float.h would have drawn Andres' ire.  We don't want
to be adding arguments to float_overflow_error/float_underflow_error;
if that were acceptable they'd not have looked like that to begin with.

Anyway, thanks for the work!  That moved us a good ways.

I think I'm going to go fix bpcharin and varcharin, because those
are the last of the SQL-spec-defined types.

			regards, tom lane





view thread (175+ messages)  latest in thread

Message-ID: <3038346.1671060258@sss.pgh.pa.us>
Permalink:  ../3038346.1671060258@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3038346.1671060258@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, sulamul@gmail.com, 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: <3038346.1671060258@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