Of course, in 7.1 foreign key constraints become rather confused when
you rename columns on them.
create table parent (id serial);
create table child (id int4 references parent(id) on update cascade);
alter table parent rename column id to anotherid;
alter table child rename column id to junk;
insert into child values (1);
-> ERROR: constraint <unnamed>: table child does now have an
attribute id
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
----- Original Message -----
From: "Brent Verner" <brent@rcfile.org>
To: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Sent: Saturday, October 06, 2001 7:49 PM
Subject: Re: [HACKERS] ALTER RENAME and indexes
> On 05 Oct 2001 at 10:18 (-0400), Brent Verner wrote:
> | On 05 Oct 2001 at 09:46 (-0400), Tom Lane wrote:
> | | Brent Verner <brent@rcfile.org> writes:
> | | > 'ALTER TABLE tbl RENAME col1 TO col2' does not update any
indices that
> | | > reference the old column name.
> | |
> | | It doesn't need to; the indexes link to column numbers, not
column
> | | names.
>
> ah, I think I see the problem... The pg_attribute.attname just needs
> updating, right? I suspect this after noticing that the
> pg_get_indexdef(Oid) function produced the correct(expected)
results,
> while those using pg_attribute were wrong.
>
> If this is the _wrong_ answer for this, stop me before I make a
> big mess :-)
>
> working...
> b
>
> --
> "Develop your talent, man, and leave the world something. Records
are
> really gifts from people. To think that an artist would love you
enough
> to share his music with anyone is a beautiful thing." -- Duane
Allman
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
majordomo@postgresql.org
>
