Tom Lane wrote:
>Andreas Pflug <pgadmin@pse-consulting.de> writes:
>
>
>>pg_get_indexdef converts that string to a list of nodes (not
>>surprising), while pg_get_expr whill join these list elements with an
>>explicit and (according to a comment, needed for partial index). Do I
>>need to retrieve indexprs and split it myself (counting brackets) or is
>>there a pg_xxx function that could help me (pg_get_element(indexprs,
>>0...n)) ?
>>
>>
>
>There isn't any real good way to do it, and I'd discourage you from
>writing client-side code that roots around in those fields anyway.
>It's much too likely to break in future versions.
>
Clearly understood, while pgadmin3 will always behave quite backend
specific. The code for index display broke just shortly ago, because the
column pg_index.indproc went away. There's a growing number of version
specific stuff in it, because we try to prevent the user from doing
illegal stuff. A backend function is certainly the better way.
>Does anyone else think it's reasonable to define a backend function
>along the lines of pg_get_indexdef(indexoid, columnnumber) that
>retrieves just the column-name-or-expression for the indicated column
>of the index?
>
There's a (pre-feature-freeze) patch pending, which implements
pg_get_indexdef(oid, int4), but the second parameter's meaning is the
pretty-print option. Now I'd rather like a function
pg_get_indexdef(indexoid, coumnnumber_int2, prettyprint_int4), I could
implement this quite fast but it's post-feature-freeze....
>I'm not eager to do it if just one person wants it, but if there's more than one potential user...
>
:-)
If it was just for my personal fun, I'd implement a module.
Regards,
Andreas
