Re: [v9.2] DROP statement reworks

The attached patches are revised ones.

* The array of ObjectProperty became a large flat data structure.
* get_object_property_xxx() put off the assumption the array of
  ObjectProperty is indexed by OBJECT_* begin from 0.
* get_object_namespace() was relocated to objectaddress.c from
  the dropcmds.c
* The logic of check_object_validation() got included within
  get_relation_address(), and rewritten more smartly, as:

+   relkind = RelationGetForm(relation)->relkind;
+   if ((objtype == OBJECT_INDEX         && relkind != RELKIND_INDEX) ||
+       (objtype == OBJECT_SEQUENCE      && relkind != RELKIND_SEQUENCE) ||
+       (objtype == OBJECT_TABLE         && relkind != RELKIND_RELATION) ||
+       (objtype == OBJECT_VIEW          && relkind != RELKIND_VIEW) ||
+       (objtype == OBJECT_FOREIGN_TABLE && relkind != RELKIND_FOREIGN_TABLE))
+       ereport(ERROR,
+               (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+                errmsg("\"%s\" is not a %s",
+                       NameListToString(objname),
+                       get_object_property_typetext(objtype))));
+

Thanks,

2011/10/5 Robert Haas <robertmhaas@gmail.com>:
> On Wed, Oct 5, 2011 at 4:47 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> The get_relation_address() follows the logic in RemoveRelations() to be
>> eliminated by this patch, so it is not a code duplication.
>> The reason why we didn't consolidate this routine with get_object_address()
>> was that remove-index requires locks on the table which owns the index to
>> be removed, and it was ugly to add an ad-hoc if-block on the routine.
>
> Yeah, that's a problem that's been in the back of my mind for a bit
> now, but I haven't come up with a good solution.  I don't think
> RemoveRelations() is the only place we have this problem, either.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



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