Re: TODO Alter Table Rename Constraint

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
>

In response to

Responses

Browse pgsql-hackers by date

  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?