On 2022-12-06 Tu 09:42, Tom Lane wrote: > [ continuing the naming quagmire... ] > > I wrote: >> Andres Freund <and...@anarazel.de> writes: >>> Not that I have a suggestion for a better name, but I don't particularly >>> like "Safe" denoting non-erroring input function calls. There's too many >>> interpretations of safe - e.g. safe against privilege escalation issues >>> or such. >> Yeah, I'm not that thrilled with it either --- but it's a reasonably >> on-point modifier, and short. > It occurs to me that another spelling could be NoError (or _noerror > where not using camel case). There's some precedent for that already; > and where we have it, it has the same implication of reporting rather > than throwing certain errors, without making a guarantee about all > errors. For instance lookup_rowtype_tupdesc_noerror won't prevent > throwing errors if catalog corruption is detected inside the catcaches. > > I'm not sure this is any *better* than Safe ... it's longer, less > mellifluous, and still subject to misinterpretation. But it's > a possible alternative. > >
Yeah, I don't think there's terribly much to choose between 'safe' and 'noerror' in terms of meaning. I originally chose InputFunctionCallContext as a more neutral name in case we wanted to be able to pass some other sort of node for the context in future. Maybe that was a little too forward looking. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
