Re: ALTER command reworks

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER command reworks
Date: 2012-10-06 18:58:24
Message-ID: CADyhKSXOCAAKireD8b53Rum-_7bcnQtED+uiK8rsQHzpjPR9Zw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2012/10/2 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
> Excerpts from Alvaro Herrera's message of vie sep 28 18:17:32 -0300 2012:
>> Excerpts from Kohei KaiGai's message of lun sep 10 08:08:32 -0300 2012:
>>
>> > As attached, I split off the original one into three portions; for set-schema,
>> > set-owner and rename-to. Please apply them in order of patch filename.
>>
>> Hmm, in the first patch, it seems to me we can simplify
>> AlterObjectNamespace's signature: instead of passing all the details of
>> the object class (cache Ids and attribute numbers and so on), just do
>>
>> AlterObjectNamespace(catalog-containing-object, objectId, newNamespaceOid)
>
> Like in the attached reworked version, in which I renamed the function
> to AlterObjectNamespace_internal because the other name seemed a bit
> wrong in the fact of the existing AlterObjectNamespace_oid.
>
> I also made the ALTER FUNCTION case go through
> AlterObjectNamespace_internal; it seems pointless to have a separate
> code path to go through when the generic one does just fine (also, this
> makes functions identical to collations in implementation). That's one
> less hook point for sepgsql, I guess.
>
Thanks for your reviewing, and sorry for my late response.

I definitely agree with your solution. The reason why my original patch
had separate code path for function and collation was they took
additional elements (such as argument-list of function) to check
duplicate names. So, I think it is a wise idea to invoke the common
code after name duplication checks.

Best regards,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John R Pierce 2012-10-06 19:13:02 Re: Bad Data back Door
Previous Message Atri Sharma 2012-10-06 18:33:33 Regarding identifying a foreign scan