From: | Viktor Valy <vili0121(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "chris(dot)gut" <chris(dot)gut(at)gmx(dot)at> |
Subject: | Re: TODO Alter Table Rename Constraint |
Date: | 2010-11-12 09:28:25 |
Message-ID: | AANLkTimpz0XLDE=N4a-o88z0BMJoN+svvBxeVY7kGttq@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
OK, I see. Thanks for mentioning it.
Are there other problems with the suggestion? Or should the work like that?
Viktor
2010/11/10 Robert Haas <robertmhaas(at)gmail(dot)com>
> On Wed, Nov 10, 2010 at 6:32 AM, Viktor Valy <vili0121(at)gmail(dot)com> wrote:
> > Thanks for your answer!
> > I'm not really familiar with inheritance, but I wonder how this issue
> > is handled in other cases, for instance renaming an index, which invokes
> > internal a constraint rename too. Is that relevant or is the renaming of
> > constraints so special?
>
> Indexes can't be inherited, so the problem doesn't arise in that case.
>
> > Is there a solution for the test-cases you have posted? Or is this yet a
> > problem?
>
> We had a bug related to the handling of ALTER TABLE .. ADD/DROP
> CONSTRAINT for those test cases, which I fixed. I think we still have
> a similar problem with ALTER TABLE .. ADD/DROP ATTRIBUTE, which I
> haven't fixed because it's hard and I haven't had time, and no one
> seems to care that much. My point was just that whatever patch you
> come up with for ALTER TABLE .. RENAME CONSTRAINT should probably be
> tested against those cases to see if it behaves correctly.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2010-11-12 10:34:42 | Re: security hooks on object creation |
Previous Message | Shigeru HANADA | 2010-11-12 09:12:32 | Re: SQL/MED estimated time of arrival? |