Re: 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(at)gmx(dot)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