Re: Show method of index - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Show method of index |
Date | |
Msg-id | B243D091-665E-41BD-B06A-BDA7C94FBECA@gmail.com Whole thread Raw |
In response to | Re: Show method of index (Greg Stark <greg.stark@enterprisedb.com>) |
Responses |
Re: Show method of index
|
List | pgsql-hackers |
On May 19, 2009, at 10:02 AM, Greg Stark <greg.stark@enterprisedb.com> wrote: > One advantage of the current arrangement is that the constraints and > triggers are almost (though not quite) in the same form as the > command to create them. It would be sad to lose that competely. Agreed. What I most often want to do is either (a) suppress all the footnotes or (b) get just the footnotes of type X and nothing else (not even the columns). But I think the tabular output is a good *option* for the second of these. I don't think I'd favor making it the ONLY option. ...Robert > > > Is there any room for a compromise? Something that just reduces the > clutter incrementally instead of completely reorganizing it? Are > there any commonalities between footnotes that could be elided if > they were grouped together differently? > > > -- > Greg > > > On 19 May 2009, at 09:41, decibel <decibel@decibel.org> wrote: > >> On May 18, 2009, at 10:25 PM, Tom Lane wrote: >>> decibel <decibel@decibel.org> writes: >>>> The gripe I have with \d is that the "footnotes" are very hard to >>>> scan through once you have more than a few things on a table. What >>>> I'd like to see is a version that provides the same information, >>>> but >>>> in a tabular output. >>> >>> Hmm, I'm not visualizing what you have in mind that would be better? >>> The difficulty with the "footnotes" is exactly that the information >>> isn't very tabular ... >> >> Instead of... >> >> Indexes: >> "debit_cards_pkey" PRIMARY KEY, btree (payment_instrument_id) >> Check constraints: >> "debit_cards__payment_instrument_type_id_must_equal_1" CHECK >> (payment_instrument_type_id = 1) >> Foreign-key constraints: >> "debit_cards_customer_id_fkey" FOREIGN KEY (customer_id) >> REFERENCES customers(id) >> "debit_cards_payment_instrument_status_id_fkey" FOREIGN KEY >> (payment_instrument_status_id) REFERENCES >> payment_instruments.payment_instrument_statuses(id) >> "debit_cards_payment_instrument_type_id_fkey" FOREIGN KEY >> (payment_instrument_type_id) REFERENCES >> payment_instruments.payment_instrument_types(id) >> Triggers: >> debit_cards__deny_delete BEFORE DELETE ON >> payment_instruments.debit_cards FOR EACH STATEMENT EXECUTE >> PROCEDURE tools.tg_disallow() >> debit_cards__dupe_id BEFORE INSERT OR UPDATE ON >> payment_instruments.debit_cards FOR EACH ROW EXECUTE PROCEDURE >> payment_instruments.tg_payment_instruments_unique() >> payment_instrument_status_history AFTER INSERT OR UPDATE ON >> payment_instruments.debit_cards FOR EACH ROW EXECUTE PROCEDURE >> payment_instruments.tg_payment_instrument_status_history() >> Inherits: payment_instruments >> >> Something more like... >> >> Inherits: payment_instruments >> >> Indexes: >> Name | Options | Method | Columns >> ------------------+---------+--------+--------------------------- >> debit_cards_pkey | PRIMARY | btree | payment_instrument_id, ... >> >> Check constraints: >> Name | >> Constraint >> ------------------------------------------------------ >> +------------------------------- >> debit_cards__payment_instrument_type_id_must_equal_1 | >> payment_instrument_type_id = 1 >> >> Foreign-key constraints: >> Name | Key >> Fields | Schema | >> Table | Foreign Keys >> ----------------------------------------------- >> +------------------------------+--------------------- >> +-----------------------------+-------------- >> debit_cards_customer_id_fkey | >> customer_id | public | >> customers | id >> debit_cards_payment_instrument_status_id_fkey | >> payment_instrument_status_id | payment_instruments | >> payment_instrument_statuses | id >> debit_cards_payment_instrument_type_id_fkey | >> payment_instrument_type_id | payment_instruments | >> payment_instrument_types | id >> >> Triggers: >> Name | When | DIU | Level | >> Schema | Function >> -----------------------------------+--------+-----+----------- >> +---------------------+--------------------------------------- >> debit_cards__deny_delete | BEFORE | D | STATEMENT | >> tools | tg_disallow() >> debit_cards__dupe_id | BEFORE | I | ROW | >> payment_instruments | tg_payment_instruments_unique() >> payment_instrument_status_history | AFTER | IU | ROW | >> payment_instruments | tg_payment_instrument_status_history() >> >> This format is a bit longer, but I think it makes it much easier to >> find information, especially on tables that have a lot of footnotes. >> >> It might also be nice to have a command that just shows the options >> on a table, and one that just shows the table columns... >> -- >> Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org >> Give your computer some brain candy! www.distributed.net Team #1828 >> >> >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
pgsql-hackers by date: