Обсуждение: need a function to extract list items from pg_node_tree
In order to implement the PARAMETER_DEFAULT column in the information schema I need a way to get the expressions out of the proargdefaults column. pg_get_expr(proargdefaults, 0) gives me all expressions comma-separated, but I need them individually. I think a function like pg_get_list_nth (to keep consistent with the internal list API) could work. Alternatively, a list-to-array function might do the trick. Are there are any other potential uses cases that should be considered here? AFAICT, indexprs is the only other system catalog column that contains an expression list.
On 2012-12-21 07:20:00 -0500, Peter Eisentraut wrote: > In order to implement the PARAMETER_DEFAULT column in the information > schema I need a way to get the expressions out of the proargdefaults > column. pg_get_expr(proargdefaults, 0) gives me all expressions > comma-separated, but I need them individually. I think a function like > pg_get_list_nth (to keep consistent with the internal list API) could > work. Alternatively, a list-to-array function might do the trick. Are > there are any other potential uses cases that should be considered here? > AFAICT, indexprs is the only other system catalog column that contains > an expression list. Hm. Wouldn't it be better to create a pg_node_tree[] and use that in pg_attribute? Its already in the variable length part of pg_proc anyway... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 12/21/12 7:26 AM, Andres Freund wrote: > On 2012-12-21 07:20:00 -0500, Peter Eisentraut wrote: >> In order to implement the PARAMETER_DEFAULT column in the information >> schema I need a way to get the expressions out of the proargdefaults >> column. pg_get_expr(proargdefaults, 0) gives me all expressions >> comma-separated, but I need them individually. I think a function like >> pg_get_list_nth (to keep consistent with the internal list API) could >> work. Alternatively, a list-to-array function might do the trick. Are >> there are any other potential uses cases that should be considered here? >> AFAICT, indexprs is the only other system catalog column that contains >> an expression list. > > Hm. Wouldn't it be better to create a pg_node_tree[] and use that in > pg_attribute? Its already in the variable length part of pg_proc > anyway... That sounds like a good idea. I don't know why they are currently stored as a list.
Peter Eisentraut <peter_e@gmx.net> writes:
> On 12/21/12 7:26 AM, Andres Freund wrote:
>> Hm. Wouldn't it be better to create a pg_node_tree[] and use that in
>> pg_attribute? Its already in the variable length part of pg_proc
>> anyway...
> That sounds like a good idea. I don't know why they are currently
> stored as a list.
They're stored as a list because that's what's convenient for use by the
parser/planner. I believe that a change like this would be quite
inconvenient on that end, and that that is not where we want to put the
inconvenience. I'm also concerned about possibly breaking any
third-party code that's already coping with the current representation.
regards, tom lane