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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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*

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Saturday, November 8, 2014, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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.

Exactly. I would like to represent the sort order of the output.

Thanks for catching it, I really need to stop writing emails without
drinking coffee...

--
Regards,

Atri
*l'apprenant*