Re: Proposal: variant of regclass
От | Tom Lane |
---|---|
Тема | Re: Proposal: variant of regclass |
Дата | |
Msg-id | 13501.1387201882@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: variant of regclass (Tatsuo Ishii <ishii@postgresql.org>) |
Ответы |
Re: Proposal: variant of regclass
|
Список | pgsql-hackers |
Tatsuo Ishii <ishii@postgresql.org> writes: > To implement toregclass, which does not throw errors when invalid > argument is given, src/backend/utils/adt/regproc.c is modified. I > added two static functions: > static Datum regclass_gut(char *class_name_or_oid, bool raiseError); > static List *stringToQualifiedNameList_gut(const char *string, bool raiseError); Please spell that as "guts" not "gut". > regclass_gut is called from regclassin and toregclass and do the most > job before regclassin did. "raiseError" flag controls whether an error > is raised or not when an invalid argument (for example non existent > relation) is given. For this purpose, regclass_gut wraps the call to > oidin using a PG_TRY block. I do not think that use of PG_TRY is either necessary or acceptable --- for example, it will happily trap and discard query-cancel errors, as well as other errors that are not necessarily safe to ignore. If you don't want to risk an error on an invalid numeric string, how about parsing the integer yourself with sscanf? More generally, though, I don't see a great need to try to promise that this function *never* throws any errors, and so I'm also suspicious of the hacking you've done on stringToQualifiedNameList. I'm even less happy about the idea that this patch might start reaching into things like makeRangeVarFromNameList. I think it's sufficient if it doesn't throw an error on name-not-found; you don't have to try to prevent weird syntax problems from throwing errors. regards, tom lane
В списке pgsql-hackers по дате отправления: