| From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Bernd Helmle <mailings(at)oopsware(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org, Thom Brown <thombrown(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Subject: | Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns |
| Date: | 2010-01-25 05:29:12 |
| Message-ID: | 4B5D2C28.7010305@ak.jp.nec.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
(2010/01/25 14:08), Robert Haas wrote:
> 2010/1/24 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> It seems to me the result is different from Bernd's report.
>
> Well, you tested something different, so you got a different answer.
> Your case doesn't have any multiple inheritance.
If it tries ALTER TABLE xxx RENAME TO on any multiple inheritance column,
this patch will raise an error when it founds the first column unable to
rename. (Of course, it takes inconsistency in table definitions, so we
need to prevent it.) It does not make sense in performance comparison.
The issue is whether we need to check pg_inherits for each recursion
level in renameatt(), or not. So, I checked the case when we try to
rename the root of inheritance tree.
Or, are you saying to test diamond-inheritance cases?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Bailey | 2010-01-25 05:29:38 | Re: Review: listagg aggregate |
| Previous Message | Takahiro Itagaki | 2010-01-25 05:28:12 | Re: Mammoth in Core? |