Re: ALTER command reworks

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, PgHacker <pgsql-hackers@postgresql.org>
Date: 2013-01-17T21:59:03Z
Lists: pgsql-hackers

Attachments

Kohei KaiGai escribió:

> This attached patch is the rebased one towards the latest master branch.

Great, thanks.  I played with it a bit and it looks almost done to me.
The only issue I can find is that it lets you rename an aggregate by
using ALTER FUNCTION, which is supposed to be forbidden.  (Funnily
enough, renaming a non-agg function with ALTER AGGREGATE does raise an
error).  Didn't immediately spot the right place to add a check.

I think these two error cases ought to have regression tests of their
own.

I attach a version with my changes.

> I noticed that your proposed design also allows to unify ALTER code of
> OPERATOR CLASS / FAMILY; that takes index access method for its
> namespace in addition to name and namespace.

Yeah, I had noticed that and was planning on implementing it later.
Thanks for saving me the work.

> So, AlterObjectRename_internal and AlterObjectNamespace_internal have
> four of special case handling to check name / namespace conflict.

Right.  (I wonder if it would make sense to encapsulate all those checks
in a single function for both to call.)

> The latest master lookups syscache within special case handing block
> as follows:
> [code]
> 
> But, we already pulls a relevant tuple from syscache on top of
> AlterObjectNamespace_internal. So, I removed cache lookup code here.

Silly me.  Thanks.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services