On 2022-12-03 Sa 16:46, Tom Lane wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> Great. Let's hope we can get this settled early next week and then we >> can get to work on the next tranche of functions, those that will let >> the SQL/JSON work restart. > OK, here's a draft proposal. I should start out by acknowledging that > this steals a great deal from Nikita's original patch as well as yours, > though I editorialized heavily. > > 0001 is the core infrastructure and documentation for the feature. > (I didn't bother breaking it down further than that.) > > 0002 fixes boolin and int4in. That is the work that we're going to > have to replicate in an awful lot of places, and I am pleased by how > short-and-sweet it is. Of course, stuff like the datetime functions > might be more complex to adapt. > > Then 0003 is a quick-hack version of COPY that is able to exercise > all this. I did not bother with the per-column flags as you had > them, because I'm not sure if they're worth the trouble compared > to a simple boolean; in any case we can add that refinement later. > What I did add was a WARN_ON_ERROR option that exercises the ability > to extract the error message after a soft error. I'm not proposing > that as a shippable feature, it's just something for testing.
Overall I think this is pretty good, and I hope we can settle on it quickly. > > I think there are just a couple of loose ends here: > > 1. Bikeshedding on my name choices is welcome. I know Robert is > dissatisfied with "ereturn", but I'm content with that so I didn't > change it here. I haven't got anything better than ereturn. details_please seems more informal than our usual style. details_wanted maybe? > > 2. Everybody has struggled with just where to put the declaration > of the error context structure. The most natural home for it > probably would be elog.h, but that's out because it cannot depend > on nodes.h, and the struct has to be a Node type to conform to > the fmgr safety guidelines. What I've done here is to drop it > in nodes.h, as we've done with a couple of other hard-to-classify > node types; but I can't say I'm satisfied with that. > > Other plausible answers seem to be: > > * Drop it in fmgr.h. The only real problem is that historically > we've not wanted fmgr.h to depend on nodes.h either. But I'm not > sure how strong the argument for that really is/was. If we did > do it like that we could clean up a few kluges, both in this patch > and pre-existing (fmNodePtr at least could go away). > > * Invent a whole new header just for this struct. But then we're > back to the question of what to call it. Maybe something along the > lines of utils/elog_extras.h ? > > Maybe a new header misc_nodes.h? Soon after we get this done I think we'll find we need to extend this to non-input functions. But that can wait a short while. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
