Andreas Pflug <[EMAIL PROTECTED]> writes: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.
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.
Does anyone else think it's reasonable to define a backend functionThere'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....
along the lines of pg_get_indexdef(indexoid, columnnumber) that
retrieves just the column-name-or-expression for the indicated column
of the index?
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
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
