Hi Haribabu Kommi Thank you so much for the review and patch update. I should have done that myself, but I've been really busy for the last few weeks. :(
Regards, Marti On Mon, Nov 16, 2015 at 4:46 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > On Thu, Nov 5, 2015 at 10:20 PM, Haribabu Kommi > <kommi.harib...@gmail.com> wrote: > > On Tue, Sep 29, 2015 at 12:17 AM, Marti Raudsepp <ma...@juffo.org> > wrote: > >> Hi list > >> > >> The attached patch changes the behavior of multiple ALTER x SET SCHEMA > >> commands, to skip, rather than fail, when the old and new schema is > >> the same. > >> > >> The advantage is that it's now easier to write DDL scripts that are > indempotent. > >> > >> This already matches the behavior of ALTER EXTENSION SET SCHEMA in > >> earlier versions, as well as many other SET-ish commands, e.g. ALTER > >> TABLE SET TABLESPACE, OWNER TO, CLUSTER ON, SET (storage_parameter...) > >> etc. I don't see why SET SCHEMA should be treated any differently. > >> > >> The code is written such that object_access_hook is still called for > >> each object. > >> > >> Regression tests included. I couldn't find any documentation that > >> needs changing. > > > > I went through the patch, following are my observations, > > > > Patch applied with hunks and compiled with out warnings. > > Basic tests are passed. > > > > In AlterTableNamespaceInternal function, if a table or matview called > > for set schema, > > If the object contains any constraints, the constraint gets updated > > with new schema. > > > > In AlterTypeNamespaceInternal function, the InvokeObjectPostAlterHook > function > > doesn't get called if the type is of composite type, domain and array > > types as because > > it just returns from top of the function. > > Most of the community members didn't find any problem in changing the > behavior, so here I attached updated patch with the above two corrections. > > Regards, > Hari Babu > Fujitsu Australia >
