Thread: Representing a SRF return column in catalogs

On Wed, Nov 5, 2014 at 8:24 AM, Atri Sharma <atri.jiit@gmail.com> wrote:
> I am working on something that requires representing a SRF return column in
> pg_proc and being able to retrieve it, retrieve the name of the column and
> make a ColumnRef node from it.
>
> The catch here are aliases:
>
> SELECT generate_series(1,100) AS a ORDER BY a;
>
> I need to know that the return column of generate_series is being referred
> as a in this query (hence tlist, sortClause will have 'c').
>
> I discussed and think that a way can be to have position of column rather
> than the actual name but that raises the question of the functionality
> needed for back resolving position to name (to make a ColumnRef node) and
> then infer that the column is being referred as an alias in this query.

It's not clear to me what you are trying to do, so I can't give you any advice.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, Nov 7, 2014 at 11:31 AM, Atri Sharma <atri.jiit@gmail.com> wrote:
> Let me give an example:
>
> Consider an user defined SRF (or an inbuilt one (generate_series)). I am
> working on a path keys tracking project (more details on it in a separate
> email). I am interested in one of the columns of the result of the SRF and
> want to store it in catalogs in a manner that allows me to refer it later
> when executing the SRF.
>
> One way can be to store the raw column name. However, I am not sure how will
> that work around aliases without a considerable fiddling with Alias nodes in
> parsetime.
>
> Can I store relattnos or something? I need to get the stored att in planner
> and build pathkeys from it.

I still can't really follow.  The columns returned by an SRF can't
change after the function is created, so the column number ought to be
stable.  The name probably will be too, though.  On the other hand,
either could get dropped and created, so then where are you?  I don't
know, because I still can't understand what you're trying to do.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Nov 7, 2014 at 11:31 AM, Atri Sharma <atri.jiit@gmail.com> wrote:
>> Can I store relattnos or something? I need to get the stored att in planner
>> and build pathkeys from it.

> I still can't really follow.  The columns returned by an SRF can't
> change after the function is created, so the column number ought to be
> stable.  The name probably will be too, though.  On the other hand,
> either could get dropped and created, so then where are you?  I don't
> know, because I still can't understand what you're trying to do.

I'm confused too.  The original example seemed to imagine that details
of a query (not the function, but the calling query) would be stored in
the catalogs, which is completely nuts.

pg_proc already has provisions to remember the names of output parameters
of a function, but it seems like you want something else than that, only
it's not very clear what.  Are you trying to say that you'd like to
represent the sort order of the output of a function?  If so, you'd have
to add new columns to pg_proc for that, but I can't see why we'd represent
that information in terms of column names.  A column number and a sort
operator would make more sense.
        regards, tom lane

I'm confused too.  The original example seemed to imagine that details
of a query (not the function, but the calling query) would be stored in
the catalogs, which is completely nuts.

pg_proc already has provisions to remember the names of output parameters
of a function, but it seems like you want something else than that, only
it's not very clear what.  Are you trying to say that you'd like to
represent the sort order of the output of a function?  If so, you'd have
to add new columns to pg_proc for that, but I can't see why we'd represent
that information in terms of column names.  A column number and a sort
operator would make more sense.