Tom Lane wrote:

Andreas Pflug <[EMAIL PROTECTED]> 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

---------------------------(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

Reply via email to