Hi Donald,
This is a feature, not a bug :-)
Seriously, pgAdmin figures out that the index is part of a constraint and classes it as a system object, therefore hiding it. If you switch on View System Objects on the View menu, you will see both indexes under the table. My guess is that pg_dump is not quite so clever and misses the UNIQUE constraint from the table definition, adding the index manually instead.
Regards, Dave.
OS W2K SP2
pgAdmin II 1.4.12
PostgreSQL 7.3 on i686-pc-linux-gnu, compiled by GCC 2.96
Another strange bug...
I create the following table using an SQL statement:
CREATE TABLE "tbl_usertype" (
"id" int4 NOT NULL,
"s_desc" varchar(60) NOT NULL,
CONSTRAINT "tbl_usertype_s_desc_key" UNIQUE ("s_desc"),
CONSTRAINT "tbl_usertype_pkey" PRIMARY KEY ("id")
) WITHOUT OIDS;
GRANT SELECT ON "tbl_usertype" TO PUBLIC;
pgAdmin then reports the following as the SQL statements:
-- Table: public.tbl_usertype
CREATE TABLE public.tbl_usertype (
id int4 NOT NULL,
s_desc varchar(60) NOT NULL,
CONSTRAINT tbl_usertype_s_desc_key UNIQUE (s_desc),
CONSTRAINT tbl_usertype_pkey PRIMARY KEY (id)
) WITHOUT OIDS;
GRANT SELECT ON TABLE public.tbl_usertype TO PUBLIC;
GRANT ALL ON TABLE public.tbl_usertype TO postgres;
Now one would expect to see under pgAdmin one Index named "tbl_usertype_s_desc_key".
pgAdmin reports zero Indexes....?
Again I checked the output from pg_dumpall and it definitely exists.
pg_dump displays the following lines.
-- Name: tbl_usertype_s_desc_key; Type: INDEX; Schema: public; Owner: postgres
CREATE UNIQUE INDEX tbl_usertype_s_desc_key ON tbl_usertype USING btree (s_desc);
Regards
Donald Fraser.
