Re: [v9.2] DROP statement reworks - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [v9.2] DROP statement reworks
Date
Msg-id CA+Tgmob35mv8y1XYbJFC6UOzsAgVcXaOvUvVEusRL78zDNcM5w@mail.gmail.com
Whole thread Raw
In response to Re: [v9.2] DROP statement reworks  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.2] DROP statement reworks
List pgsql-hackers
On Wed, Sep 28, 2011 at 11:51 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> I rebased the patches towards the latest git master, so I believe these
> are available to apply.

Reviewing away...

I don't see why we need one struct called ObjectProperty and another
called CatalogProperty.  Just fold CatalogProperty into ObjectProperty
and make it one big flat structure.

The get_object_property_waddawadda functions appear to be designed
under the assumption that each object type will be in the
ObjectProperty structure at the offset corresponding to (int) objtype.Are these functions going to get called from any
placethat's
 
performance-critical enough to justify that optimization?  I'd rather
just have these functions use linear search, so that if someone adds a
new OBJECT_* constant and doesn't add it to the array it doesn't
immediately break everything.

get_object_namespace() looks like it ought to live in objectaddress.c,
not dropcmds.c.  check_object_validation() doesn't seem like a very
good description of what that code actually does -- and that code
looks like it's copy-and-pasted from elsewhere.  Can we avoid that?
get_relation_address() is surely a copy of some other bit of code; how
can we avoid duplication?

Setting status to "Waiting on Author".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Unremovable tuple monitoring (was: Addition of some trivial auto vacuum logging)
Next
From: Simon Riggs
Date:
Subject: Re: [REVIEW] pg_last_xact_insert_timestamp