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>
