Re: [v9.2] DROP statement reworks

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [v9.2] DROP statement reworks
Date: 2011-10-04 13:00:39
Message-ID: CA+Tgmob35mv8y1XYbJFC6UOzsAgVcXaOvUvVEusRL78zDNcM5w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 28, 2011 at 11:51 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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 place that'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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-10-04 13:15:11 Re: [REVIEW] pg_last_xact_insert_timestamp
Previous Message Robert Haas 2011-10-04 12:26:32 Re: [PATCH] Unremovable tuple monitoring (was: Addition of some trivial auto vacuum logging)