Re: ALTER command reworks

The attached patch is a refreshed version of ALTER command
reworks towards the latest tree. Here is few big changes except
for code integration of the code to rename event triggers.

BTW, I had to adjust between oid of pg_largeobject_metadata
and pg_largeobject on three points of this patch, like:

        if (classId == LargeObjectRelationId)
            classId = LargeObjectMetadataRelationId;

When we supported largeobject permission features, we put
special handling to track dependency of its ownership.
The pg_depend records oid of pg_largeobject, instead of
pg_largeobject_metadata. Thus, we cannot use classId of
ObjectAddress being returned from get_object_address()
as an argument of heap_open() as is, if it indicates oid of
pg_largeobject.

Was it a right decision to track dependency of large object using
oid of pg_largeobject, instead of pg_largeobject_metadata?
IIRC, the reason why we used oid of pg_largeobject is backward
compatibility for applications that tries to reference pg_depend
with built-in oids.

Don't we need to change the specification?
Or, do we continue to implement the code carefully?

Thanks,

2012/7/24 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> The attached patch is my homework at the last commit fest of v9.2.
>
> It consolidates some similar routines into a single generic routines
> that handles ALTER RENAME TO, OWNER TO and SET SCHEMA
> according to the ObjectProperty in objectaddress.c, but here is
> no functionality enhancement.
>
> As existing AlterObjectNamespace() doing, this generic routine
> handles only case when a catalog entry is updated without any
> extra permission checks or other stuffs.
> Thus, RenameSchema was not consolidated due to CREATE
> permission checks towards the database, for example.
>
> As patched chunk in commands/alter.c shows, 13 of special
> routines were consolidated into AlterObjectRename, 16 of
> special ones were consolidated into AlterObjectNamespace,
> and 20 of special ones were consolidated into AlterObjectOwner().
>
> My motivation is for minimization of number of places to put
> object-access-hook around alter statement. Probably, it shall
> be located around or just after simple_heap_update().
> This is a groundwork towards ALTER command support in
> sepgsql module.
>
> Thanks,
> --
> KaiGai Kohei <kaigai@kaigai.gr.jp>



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