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

From Tom Lane
Subject Re: Representing a SRF return column in catalogs
Date
Msg-id 14650.1415396542@sss.pgh.pa.us
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  (Atri Sharma <atri.jiit@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: printing table in asciidoc with psql
Next
From: Alvaro Herrera
Date:
Subject: Re: split builtins.h to quote.h