Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt
Date
Msg-id BANLkTikLq_V9AmZUuTxKf-uhtQjyw9eHMA@mail.gmail.com
Whole thread Raw
In response to [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt
List 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@kaigai.gr.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@kaigai.gr.jp>
>



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

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Your Postgresql 9.2 patch
Next
From: Shigeru Hanada
Date:
Subject: Re: per-column generic option