Re: Show method of index - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Show method of index
Date
Msg-id 2450.1242084012@sss.pgh.pa.us
Whole thread Raw
In response to Re: Show method of index  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Show method of index  (Greg Stark <stark@enterprisedb.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Khee Chin escribi�:
>> Updated with an additional line in the comments for get_indexdef
>> 
>> *      if colno == -999, we only want the name of the variables that
>> make up the index

> I don't think this hack is going to fly.

Yeah ... if it were local in describe.c that would be one thing, but
putting such a kluge in a public function API is pretty icky.

I think the proposed patch is doing pretty much the wrong thing anyhow.
As I understood it, the request was *not* to add a column to \di (which
would likely make it too wide to be readable, and would look rather
silly in a mixed-indexes-and-tables listing too).  The idea was to add
a column to \d for an index, ie given something like

CREATE INDEX fooi ON foo (f1, (f2+f3))

then "\d fooi" would give
        Index "public.fooi"    Column      |  Type   | Definition
-----------------+---------+------------f1              | integer | f1pg_expression_2 | integer | (f2+f3)

which you could do straight off with the existing behavior of
pg_get_indexdef().

BTW, if we're going to have a different columnset for \d on indexes,
it seems like it would be a good idea to include the opclass name too,
at least in \d+.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Next
From: Greg Stark
Date:
Subject: Re: Show method of index