Greetings,
Not entirely sure if this would be considered a 'bug' but it's
certainly annoying and creates some confusion. Basically, it's like
this:
test=3D> create table a (
test(> b int primary key
test(> );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "a_pkey" for=
table "a"
CREATE TABLE
test=3D> \d a
Table "sfrost.a"
Column | Type | Modifiers=20
--------+---------+-----------
b | integer | not null
Indexes:
"a_pkey" PRIMARY KEY, btree (b)
-- Now, attempt to rename the table, and associated stuff
test=3D> alter table a rename to c;
ALTER TABLE
test=3D> alter index a_pkey rename to c_pkey;
ALTER INDEX
test=3D> \d c
Table "sfrost.c"
Column | Type | Modifiers=20
--------+---------+-----------
b | integer | not null
Indexes:
"c_pkey" PRIMARY KEY, btree (b)
-- All looks good, but there's something hidden...
test=3D> \q
> pg_dump -s -n sfrost test
--
-- PostgreSQL database dump
--
[...]
CREATE TABLE c (
b integer NOT NULL
);
[...]
ALTER TABLE ONLY c
ADD CONSTRAINT a_pkey PRIMARY KEY (b);
[...]
--
-- PostgreSQL database dump complete
--
The *constraint* name isn't changed, and that's what pg_dump uses. Fair
enough on pg_dump's part, but it's very confusing that \d (or even \d++)
doesn't show the issue that's created by just renaming the index. It
would seem to me that \d can use its current format when the names are
the same, but if they're different it should display the index and the
constraint seperately.
Sorry, havn't really got time to write a patch at the moment. Hopefully
someone might have a minute to look into it tho.
Thanks,
Stephen
