>>> On Wed, Jan 16, 2008 at 5:20 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> 2. Make ALTER INDEX RENAME automatically rename the constraint, too.
> 3. Invent an ALTER TABLE RENAME CONSTRAINT command, and have it also
> rename the underlying index.
> I'm thinking
Decibel! <[EMAIL PROTECTED]> writes:
> On Jan 16, 2008, at 5:20 PM, Tom Lane wrote:
>> There seem to be three things we could do:
>>
>> 1. Make ALTER INDEX RENAME fail if the index belongs to a constraint.
>> This is trivial code-wise, but doesn't seem especially helpful to
>> users.
> +1. IMO,
On Jan 16, 2008, at 5:20 PM, Tom Lane wrote:
There was some discussion last week on -bugs about how renaming an
index
that belongs to a unique or primary key constraint is allowed, but can
lead to situations that can't be dumped/restored properly. This isn't
really pg_dump's fault, IMHO. We s
Tom Lane wrote:
There was some discussion last week on -bugs about how renaming an index
that belongs to a unique or primary key constraint is allowed, but can
lead to situations that can't be dumped/restored properly. This isn't
really pg_dump's fault, IMHO. We should rather make the backend
There was some discussion last week on -bugs about how renaming an index
that belongs to a unique or primary key constraint is allowed, but can
lead to situations that can't be dumped/restored properly. This isn't
really pg_dump's fault, IMHO. We should rather make the backend enforce
that the in
