From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: describe objects, as in pg_depend |
Date: | 2010-11-18 17:49:21 |
Message-ID: | 3754.1290102561@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-18 17:54:14 | Re: final patch - plpgsql: for-in-array |
Previous Message | Pavel Stehule | 2010-11-18 17:43:29 | Re: final patch - plpgsql: for-in-array |