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

From Kohei KaiGai
Subject [v9.2] DROP statement reworks
Date
Msg-id CADyhKSX+ud30gCNnyq16Yhh2=EMkyUtxvvgBvPhjgC8coBcvzg@mail.gmail.com
Whole thread Raw
Responses Re: [v9.2] DROP statement reworks
List pgsql-hackers
The attached three patches try to consolidate code path of DROP
statement on various kind of object classes.

The first part provides a set of internal api to reference properties
of object types; as we had a discussion before.
It adds a big static array indexed by ObjectType; that holds OID of
corresponding catalog, catcache id, attribute number of name,
namespace, owner and so on. Every field of this array is accessable
via get_object_property_*() interfaces.
As a proof-of-concept, I reworked object_exists() with this array to
lookup a heaptuple by the supplied ObjectAddress.

The second part is a revised one from what I submitted in the commit-fest July.
It consolidate existing code paths corresponding to DropStmt (schema,
relations, text searches, type, domain, extension, conversion,
collation).

The third part is more reworks for other object classes (aggregate,
function, language, foreign data wrapper, foreign server, cast,
operator, trigger, rule).

I don't touch on shared database objects (database, tablespace and
role) because its behavior on deletion is not compatible with any
other object classes. So, it is unclear for me whether it is a
suitable case to be consolidated.
And, I also don't touch code corresponding to user-mapping because it
is not supported by get_object_address() yet.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Should we have an optional limit on the recursion depth of recursive CTEs?
Next
From: Magnus Hagander
Date:
Subject: Re: walprotocol.h vs frontends