On Fri, Dec 16, 2022 at 1:31 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > The reg* functions probably need a unified plan as to how far > down we want to push non-error behavior. The rest of these > I think just require turning the crank along the same lines > as in functions already dealt with.
I would be in favor of an aggressive approach. For example, let's look at regclassin(). It calls oidin(), stringToQualifiedNameList(), makeRangeVarFromNameList(), and RangeVarGetRelidExtended(). Basically, oidin() could fail if the input, known to be all digits, is out of range; stringToQualifiedNameList() could fail due to mismatched delimiters or improperly-separated names; makeRangeVarFromNameList() doesn't want to have more than three name components (db.schema.relation); and RangeVarGetRelidExtended() doesn't like cross-database references or non-existent relations. Now, one option here would be to distinguish between something that could be valid in some database but isn't in this one, like a non-existent relation name, and one that couldn't ever work anywhere, like a relation name with four parts or bad quoting. You could decide that the former kind of error will be reported softly but the latter is hard error. But I think that is presuming that we know how users will want to use this functionality, and I don't think we do. I also think that it will be confusing to users. Finally, I think it's different from what we do for other data types. You could equally well argue that, for int4in, we ought to treat '9999999999' and 'potato' differently, one a hard error and the other soft. I think it's hard to puzzle out a decision that makes any sense there, and I don't think this case is much different. I don't think it's too hard to mentally separate errors about the validity of the input from, say, out of memory errors -- but one distinguishing between one kind of input validity check and another seems like a muddle. It also doesn't seem too bad from an implementation point of view to try to cover all the caes. The stickiest case looks to be RangeVarGetRelidExtended() and we might need to give a bit of thought to how to handle that one. The others don't seem like a big issue, and oidin() is already done. > While it'd be good to get all of these done before v16 feature > freeze, I can't see that any of them represent blockers for > building features based on soft input error handling. +1. -- Robert Haas EDB: http://www.enterprisedb.com