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

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

In response to

Responses

Browse pgsql-hackers by date

  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