Re: postgres C function returning SETOF record gives RECORD TYPE NOT REGISTERED

to add a little clarification to the problem description, the transformed
query (one which is actually run) returns the same result as the submitted
query so actually the caller knows the number and type of fields to expect
but they can be different for different calls as any query can be specified
as the argument of the function.So would I have to create a placeholder type
for each run of the query or what ??

thanks and regards
rajarshi
------------------------------------------------------------------------------

On Thu, Jun 4, 2009 at 6:23 PM, raajarshi . <raajarshi(at)sify(dot)com> wrote:

>
>
> Hi,
> I am a rather new user of Postgresql. I have a problem with writing a C
> function that returns a SETOF records.
>
> My function will take a query as its lone parameter and will process this
> query to create a new one. This new query will be executed and the results
> returned.
> I have written a C function which returns a SETOF record and takes a
> varchar as input. There are no OUT parameters. I use SPI to execute the
> final query. After that I have the tuple descriptor and an array of rows to
> return. When I go to return the rows, I get the error 'RECORD TYPE HAS NOT
> BEEN REGISTERED'.
>
> I want to know if there is a way to dynamically determine the return type(
> and to tell the caller function what to expect from this call) when I am
> already inside the function. As far as I can see (though it is not too far)
> we have all the information like result type etc after executing the final
> query.
>
> Are there any functions which take the tuple descriptor and OID of a
> function and fill up all the leftover bits and pieces so that by the time
> the function returns, every other thing is in place.
>
> If someone thinks this solution can be implemented in some other way,
> please suggest. Just to remind, the function will accept ANY query of any
> kind but run a transformed query. So at the time of calling, we do not know
> what is going to actually run but once we run it and have the results, we
> know everything that is of consequence.
>
>
> thanks
> rajarshi
>