I think that's a lot more useful than the previous changes I submitted that
just broke them into index type.
I'm in favour of it.
Chris
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org]On Behalf Of Greg Sabino
Mullane
Sent: Thursday, 8 November 2001 11:08 PM
To: pgsql-patches@postgresql.org
Subject: [PATCHES] Enhanced index details using \d in psql
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've revised my patch to use the pg_get_indexdef function, as
suggested by Tom Lane. When doing a \d in psql, it shows not
only the name of the index, but which columns it uses,
what type of index it is (btree, hash, etc.), whether it
is unique or a primary key, and (thanks to the pg_get_indexdef
magic) information about functional and partial indexes.
I also made the ORDER BY stick the primary keys and unique
indexes at the top of the list, then alphabetasize the rest,
which I think is a good trade off for having ruined the
previous "separation" of the 3 types of indexes.
Here is some sample output:
CREATE TABLE PIZZA (
slicename VARCHAR(10) PRIMARY KEY,
crust VARCHAR(12),
topping INTEGER
);
CREATE INDEX banana ON pizza (crust);
CREATE UNIQUE INDEX watermelon ON pizza (topping);
CREATE INDEX apple ON pizza USING hash (topping) WHERE (topping > 99);
CREATE INDEX peach ON pizza (lower(crust));
bakery=# \d pizza
Table "pizza"
Column | Type | Modifiers
- -----------+-----------------------+-----------
slicename | character varying(10) | not null
crust | character varying(12) |
topping | integer |
Indexes: pizza_pkey primary key btree (slicename),
watermelon unique btree (topping),
apple hash (topping) WHERE (topping > 99),
banana btree (crust),
peach btree (lower(crust))
Greg Sabino Mullane
greg@turnstep.com
PGP Key: 0x14964AC8 200111081007
-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html
iQA/AwUBO+qfuLybkGcUlkrIEQKFNgCg0ycYPt5DMvXI8EH/CH2mc8ZOJYwAoK1x
RDPvYrxuU55Sp1UIYgTWCRdD
=VBAa
-----END PGP SIGNATURE-----