Skip site navigation (1) Skip section navigation (2)

Re: Accessing original TupleDesc from SRF

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Gray <jgray(at)azuli(dot)co(dot)uk>
Cc: Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Accessing original TupleDesc from SRF
Date: 2002-08-30 14:21:57
Message-ID: 309.1030717317@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
John Gray <jgray(at)azuli(dot)co(dot)uk> writes:
> Please correct me if I've got this wrong, but it appears from the SRF
> API, that a SRF cannot readily refer to the TupleDesc to which it is
> expected to conform (i.e. the TupleDesc derived from the FROM clause of
> an original SELECT statement) because that is held in the executor state
> and not copied or linked into the function context.

> The reason I'm interested (and this might be a crazy idea) is that a
> function might choose to adapt its output based on what it is asked for.

Seems like a cool idea.

We could fairly readily add a field to ReturnSetInfo, but that would
only be available to functions defined as returning a set.  That'd
probably cover most useful cases but it still seems a bit unclean.

I suppose that ExecMakeTableFunctionResult could be changed to *always*
pass ReturnSetInfo, even if it's not expecting the function to return
a set.  That seems even less clean; but it would work, at least in the
current implementation.

Anyone have a better idea?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Lamar OwenDate: 2002-08-30 14:35:39
Subject: Re: contrib features during beta period
Previous:From: Tom LaneDate: 2002-08-30 13:44:03
Subject: Re: Fulltextindex

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group