Re: Error-safe user functions

On 2022-12-06 Tu 15:21, Tom Lane wrote:
> OK, here's a v3 responding to the comments from Andres.

Looks pretty good to me.

>
> 0000 is preliminary refactoring of elog.c, with (I trust) no
> functional effect. It gets rid of some pre-existing code duplication
> as well as setting up to let 0001's additions be less duplicative.
>
> 0001 adopts use of Node pointers in place of "void *". To do this
> I needed an alias type in elog.h equivalent to fmgr.h's fmNodePtr.
> I decided that having two different aliases would be too confusing,
> so what I did here was to converge both elog.h and fmgr.h on using
> the same alias "typedef struct Node *NodePtr". That has to be in
> elog.h since it's included first, from postgres.h. (I thought of
> defining NodePtr in postgres.h, but postgres.h includes elog.h
> immediately so that wouldn't have looked very nice.)
>
> I also adopted Andres' recommendation that InputFunctionCallSafe
> return boolean. I'm still not totally sold on that ... but it does
> end with array_in and record_in never using SAFE_ERROR_OCCURRED at
> all, so maybe the idea's OK.

Originally I wanted to make the new function look as much like the
original as possible, but I'm not wedded to that either. I can live with
it like this.

>
> 0002 adjusts the I/O functions for these API changes, and fixes
> my silly oversight about error cleanup in record_in.
>
> Given the discussion about testing requirements, I threw away the
> COPY hack entirely. This 0003 provides a couple of SQL-callable
> functions that can be used to invoke a specific datatype's input
> function. I haven't documented them, pending bikeshedding on
> names etc. I also arranged to test array_in and record_in with
> a datatype that still throws errors, reserving the existing test
> type "widget" for that purpose.
>
> (I'm not intending to foreclose development of new COPY features
> in this area, just abandoning the idea that that's our initial
> test mechanism.)
>

The new functions on their own are likely to make plenty of people quite
happy once we've adjusted all the input functions.

Perhaps we should add a type in the regress library that will never have
a safe input function, so we can test that the mechanism works as
expected in that case even after we adjust all the core data types'
input functions.

Otherwise I think we're good to go.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com