From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | PgHacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.2] DROP Reworks Part.0 - 'missing_ok' support of get_object_address |
Date: | 2011-06-19 02:51:53 |
Message-ID: | BANLkTimb8G4bjUoybeCtP61+oHt-CGxocA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 14, 2011 at 8:06 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> The attached patch is a preparation to rework implementation of DROP statement
> using a common code. That intends to apply get_object_address() to resolve name
> of objects to be removed, and eventually minimizes the number of places to put
> permission checks.
>
> Its first step is an enhancement of get_object_address; to accept 'missing_ok'
> argument to handle cases when IF EXISTS clause is supplied.
> If 'missing_ok' was true and the supplied name was not found, the patched
> get_object_address() returns an ObjectAddress with InvalidOid as objectId.
> If 'missing_ok' was false, its behavior is not changed.
Let's consistently make missing_ok the last argument to all of the
functions to which we're adding it.
I don't think it's a good idea for get_relation_by_qualified_name() to
be second-guessing the error message that RangeVarGetRelid() feels
like throwing.
I think that attempting to fetch the column foo.bar when foo doesn't
exist should be an error even if missing_ok is true. I believe that's
consistent with what we do elsewhere. (If it *were* necessary to open
the relation without failing if it's not there, you could use
try_relation_openrv instead of doing as you've done here.)
There is certainly a more compact way of writing the logic in
get_object_address_typeobj. Also, I think that function should be
called get_object_address_type(); the "obj" on the end seems
redundant.
Apart from those comments this looks pretty sensible.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-19 02:57:13 | Re: Identifying no-op length coercions |
Previous Message | Noah Misch | 2011-06-19 02:41:25 | Re: crash-safe visibility map, take five |