Re: describe objects, as in pg_depend

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2010-11-18T17:49:21Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. has_table_privilege spawns scions has_database_privilege, has_function_privilege,

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