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  (Tom Lane <tgl@sss.pgh.pa.us>)
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:

Previous
From: Greg Stark
Date:
Subject: Re: Show method of index
Next
From: Tom Lane
Date:
Subject: Re: Show method of index