Error-safe user functions - Mailing list pgsql-hackers

Hi, hackers!


Trying to implement error handling behavior required by SQL/JSON, we
came to agreement that we need special infrastructure for catching
errors in the input and type conversion functions without heavy-weight
things like subtransactions.  See the whole thread "SQL/JSON features
for v15" [1], or last ~5  messages in the branch starting from [2].

The idea is simple -- introduce new "error-safe" calling mode of user 
functions by passing special node through FunctCallInfo.context, in 
which function should write error info and return instead of throwing 
it.  Also such functions should manually free resources before 
returning an error.  This gives ability to avoid PG_TRY/PG_CATCH and 
subtransactions.


I have submitted two patch sets to the old thread: the first [3] POC 
example for NULL_ON_ERROR option for COPY, and the second [4] with the 
set of error-safe functions needed for SQL/JSON.

Now I'm starting this separate thread with the new version of the
patch set, which includes error-safe functions for the subset of
data types (unfinished domains were removed), NULL_ON_ERROR option 
for COPY (may need one more thread).



In the previous version of the patch error-safe functions were marked
in the catalog using new column pg_proc.proissafe, but it is not the
best solution:

On 30.09.2022, Tom Lane wrote:
> I strongly recommend against having a new pg_proc column at all.
> I doubt that you really need it, and having one will create
> enormous mechanical burdens to making the conversion.  (For example,
> needing a catversion bump every time we convert one more function,
> or an extension version bump to convert extensions.)

I think the only way to avoid catalog modification (adding new columns
to pg_proc or pg_type, introducing new function signatures etc.) and
to avoid adding some additional code to the entry of error-safe
functions is to bump version of our calling convention.  I simply added
flag Pg_finfo_record.errorsafe which is set to true when the new
PG_FUNCTION_INFO_V2_ERRORSAFE() macro is used.  We could avoid adding
this flag by treating every V2 as error-safe, but I'm not sure if
it is acceptable.

Built-in error-safe function are marked in pg_proc.dat using the 
special flag "errorsafe" which is stored only in FmgrBuiltin, not in 
the catalog like previous "proissafe" was.


> On 2022-09-3 Andrew Dunstan wrote:
>> I suggest just submitting the Input function stuff on its own, I
>> think that means not patches 3,4,15 at this stage. Maybe we would
>> also need a small test module to call the functions, or at least
>> some of them.  The earlier we can get this in the earlier SQL/JSON
>> patches based on it can be considered.

> +1

I have added test module in patch #14.

> On 2022-09-3 Andrew Dunstan wrote:
> proissafe isn't really a very informative name. Safe for what? maybe
> proerrorsafe or something would be better?

I have renamed "safe" to "errorsafe".


On 2022-09-3 Andrew Dunstan wrote:
> I don't think we need the if test or else clause here:
>
> +   if (edata)
> +       return InputFunctionCallInternal(flinfo, str, typioparam,
> typmod, edata);
> +   else
> +       return InputFunctionCall(flinfo, str, typioparam, typmod);
"If" statement removed.


On 2022-09-3 Andrew Dunstan wrote:
> I think we should probably cover float8 as well as float4, and there
> might be some other odd gaps.

I have added error-safe function for float8 too.


[1] https://www.postgresql.org/message-id/flat/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
[2] https://www.postgresql.org/message-id/flat/13351.1661965592%40sss.pgh.pa.us#3d23aa20c808d0267ac1f7ef2825f0dd
[3] https://www.postgresql.org/message-id/raw/379e5365-9670-e0de-ee08-57ba61cbc976%40postgrespro.ru
[4] https://www.postgresql.org/message-id/raw/0574201c-bd35-01af-1557-8936f99ce5aa%40postgrespro.ru

-- 
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company