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(at)gmail(dot)com>:
> On Wed, Oct 5, 2011 at 4:47 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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(at)kaigai(dot)gr(dot)jp>