2010/1/3 KaiGai Kohei <kai...@ak.jp.nec.com>: > (2010/01/04 4:06), Robert Haas wrote: >> On Jan 3, 2010, at 12:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> In practice the reasonable engineering alternatives may just be to do >>> what KaiGai's patch does, or to do nothing. In that case I think a good >>> argument can be made for the latter. Nobody has ever complained about >>> this from the field AFAIR; but we might get complaints if we disable >>> cases that used to work fine. >> >> Maybe. The current behavior of allowing the rename but then breaking >> queries certainly isn't awesome. I think if someone is willing to >> implement a more careful check we should accept it. > > The condition to prevent problematic renaming might be modified to handle > diamond inheritances correctly. > > The current patch raises an error when pg_attribute.inhcount > 1. > But, in actually, it should raise an error when the number of origins > of the attribute to be renamed is larger than 1. > It shall be match with the inhcount unless it does not have diamond > inheritances. > > We can easily check the number of origins with walking on the pg_inherits > catalog. So, it seems to me the condition should be rewritten like: > > BEFORE: > if (attform->attinhcount > 1) > ereport(ERROR, ...); > > AFTER: > if (number_of_attribute_origin(myrelid, oldattname) > 1) > ereport(ERROR, ...); > > Am I missing something?
That sounds about right to me, though that function doesn't exist yet. :-) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
