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: | Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt |
Date: | 2011-06-28 08:17:51 |
Message-ID: | BANLkTikLq_V9AmZUuTxKf-uhtQjyw9eHMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The attached patch is rebased one to consolidate routines to remove objects
using the revised get_object_address().
The new RemoveObjects() replaces the following routines; having
similar structure.
- RemoveRelations
- RemoveTypes
- DropCollationsCommand
- DropConversionsCommand
- RemoveSchemas
- RemoveTSParsers
- RemoveTSDictionaries
- RemoveTSTemplates
- RemoveTSConfigurations
- RemoveExtensions
I guess the most arguable part of this patch is modifications to
get_relation_by_qualified_name().
This patch breaks down the relation_openrv_extended() into
a pair of RangeVarGetRelid() and relation_open() to inject
LockRelationOid() between them, because index_drop() logic
requires the table owning the target index to be locked prior to
the index itself.
Thanks,
2011/6/14 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> The attached patch can be applied on the part-0 patch, and enables to
> consolidate routines to handle DropStmt into one common function;
> void RemoveObjects(DropStmt *stmt);
>
> The top-half of object deletion steps are almost consist of the following steps.
> 1) Look up object-Id of the supplied object name
> If not found, it raises an error or a notice with skip this deletion.
> 2) Apply ownership checks on the target object itself or the schema
> that underlies
> the target object.
> 3) Add the ObjectAddress of the target object into ObjectAddresses, then invokes
> performMultipleDeletions() or performDeletion().
>
> However, we don't need to have individual routines for each object classes,
> because get_object_address takes up the portion of (1), and
> check_object_ownership also takes up the portion of (2).
> Here is no differences between most of objects classes on the (3).
>
> So, the new RemoveObjects() consolidates routines to handle DropStmt for
> each object classes. Instead of this common function, the following routines
> were eliminated.
> RemoveRelations(DropStmt *drop);
> RemoveTypes(DropStmt *drop);
> DropCollationsCommand(DropStmt *drop);
> DropConversionsCommand(DropStmt *drop);
> RemoveSchemas(DropStmt *drop);
> RemoveTSParsers(DropStmt *drop);
> RemoveTSDictionaries(DropStmt *drop);
> RemoveTSTemplates(DropStmt *drop);
> RemoveTSConfigurations(DropStmt *drop);
> RemoveExtensions(DropStmt *drop);
>
> Routines to handle other DROP statement (such as RemoveFuncStmt or
> DropPLangStmt) are not scope of this patch to restrain the patch size.
> However, it is not a tough work to fit these objects with this structure.
> (It may need a discussion for databases, tablespaces and roles)
>
> Thanks,
> --
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Attachment | Content-Type | Size |
---|---|---|
pgsql-v9.2-drop-reworks-part-1.v2.patch | application/octet-stream | 54.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Shigeru Hanada | 2011-06-28 12:06:40 | Re: per-column generic option |
Previous Message | Simon Riggs | 2011-06-28 08:06:56 | Re: Your Postgresql 9.2 patch |