From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_get_INDEXdef - opclass |
Date: | 2006-06-13 08:13:51 |
Message-ID: | E7F85A1B5FF8D44C8A1AF6885BC9A0E4013888C6@ratbert.vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 12 June 2006 18:32
> To: Dave Page
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] pg_get_INDEXdef - opclass
>
> "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> writes:
> >> Following a pgAdmin bug report, I noticed that
> pg_get_viewdef doesn't
> >> return the opclass when called for a specific column (in 8.1
> >> at least) -
>
> > Bah, I mean pg_get_indexdef of course :-)
>
> This is intentional --- whoever asked for the per-column variant of
> the indexdef function wanted it that way. It seems reasonable to me:
> you can extract the opclass name with a simple join against
> pg_index.indclass[N], when you need it, whereas if the function
> sometimes included an opclass name that would tend to break apps that
> weren't expecting it. OTOH, getting the expression for an expression
> column would be seriously painful if there were no function to do it.
Right, but how can I conditionally join with pg_opclass based on whether
or not the opclass specified for the column is the default for that
type? For a base type index column I can probably do that with some SQL,
but what about cases where the index column is an expression?
Regards, Dave.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2006-06-13 08:27:05 | Re: [PATCHES] Non-transactional pg_class, try 2 |
Previous Message | Bruno Wolff III | 2006-06-13 04:25:56 | Re: Ranges for well-ordered types |