Re: Representing a SRF return column in catalogs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Representing a SRF return column in catalogs
Date: 2014-11-07 21:42:22
Message-ID: 14650.1415396542@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Nov 7, 2014 at 11:31 AM, Atri Sharma <atri(dot)jiit(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-11-07 21:42:55 Re: split builtins.h to quote.h
Previous Message Alvaro Herrera 2014-11-07 21:37:13 Re: printing table in asciidoc with psql