Re: describe objects, as in pg_depend
От | Tom Lane |
---|---|
Тема | Re: describe objects, as in pg_depend |
Дата | |
Msg-id | 3754.1290102561@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: describe objects, as in pg_depend (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: describe objects, as in pg_depend
Re: describe objects, as in pg_depend |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > In the process of looking it over again, I noticed that in an > assert-enabled build, it's trivial to crash the server with this > function: just pass a nonzero subobjid with an object class that doesn't > take one. This could be fixed easily by turning the Asserts into > elog(ERROR). > Another problem with this function is that a lot of checks that > currently raise errors with elog(ERROR) are now user-facing. On this > issue one possible answer would be to do nothing; another would be to go > over all those calls and turn them into full-fledged ereports. Yeah, it would definitely be necessary to ensure that you couldn't cause an Assert by passing bogus input. I wouldn't bother making the errors into ereports though: that's adding a lot of translation burden to no good purpose. Please do not do this: +/* this doesn't really need to appear in any header file */ +Datum pg_describe_object(PG_FUNCTION_ARGS); Put the extern declaration in a header file, don't be cute. This is useless, because getObjectDescription never returns null (or if it does, we have a whole lot of unprotected callers to fix): + if (!description) + ereport(ERROR, + (errcode(ERRCODE_INVALID_OBJECT_DEFINITION), + errmsg("invalid object specification"))); regards, tom lane
В списке pgsql-hackers по дате отправления: