Re: Show method of index

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
Cc: decibel <decibel(at)decibel(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Ricardo Bessa <ricardobessa(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Show method of index
Date: 2009-05-19 14:09:15
Message-ID: B243D091-665E-41BD-B06A-BDA7C94FBECA@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On May 19, 2009, at 10:02 AM, Greg Stark <greg(dot)stark(at)enterprisedb(dot)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(at)decibel(dot)org> wrote:
>
>> On May 18, 2009, at 10:25 PM, Tom Lane wrote:
>>> decibel <decibel(at)decibel(dot)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(at)decibel(dot)org
>> Give your computer some brain candy! www.distributed.net Team #1828
>>
>>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sam Mason 2009-05-19 14:12:03 Re: INTERVAL data type and libpq - what format?
Previous Message Greg Stark 2009-05-19 14:02:20 Re: Show method of index