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
