Re: Representing a SRF return column in catalogs - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: Representing a SRF return column in catalogs
Date
Msg-id CAOeZVifrk96JdzNePsoF+tcpooJWdomr38NV_CuAwnK8_ZQ1nA@mail.gmail.com
Whole thread Raw
In response to Re: Representing a SRF return column in catalogs  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Representing a SRF return column in catalogs  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


On Fri, Nov 7, 2014 at 7:15 PM, Robert Haas <robertmhaas@gmail.com> wrote:
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.

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.

Please advice.

Regards,

Atri



--
Regards,
 
Atri
l'apprenant

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: row_to_json bug with index only scans: empty keys!
Next
From: Petr Jelinek
Date:
Subject: Re: Sequence Access Method WIP