[v9.2] DROP statement reworks

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: [v9.2] DROP statement reworks
Date: 2011-08-15 19:47:07
Message-ID: CADyhKSX+ud30gCNnyq16Yhh2=EMkyUtxvvgBvPhjgC8coBcvzg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)kaigai(dot)gr(dot)jp>

Attachment Content-Type Size
pgsql-v9.2-drop-rework-3.v1.patch application/octet-stream 50.2 KB
pgsql-v9.2-drop-rework-1.v1.patch application/octet-stream 16.7 KB
pgsql-v9.2-drop-rework-2.v1.patch application/octet-stream 44.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2011-08-15 19:49:41 Should we have an optional limit on the recursion depth of recursive CTEs?
Previous Message Simon Riggs 2011-08-15 19:12:25 Re: walprotocol.h vs frontends