Обсуждение: anonymous composite types - how to pass tupdesc to the function

I'm looking at modifications to dblink to allow it to make use of table 
functions. One item which is very much needed is the ability to define 
dblink as returning setof record, so that it can return a tuple as 
described at runtime in the query string.

I'm trying to come up with the best method to pass the query string 
columndef, or better yet the tuple description, to the function. Any 
suggestions on an approach?

Thanks,

Joe

Joe Conway <mail@joeconway.com> writes:
> I'm trying to come up with the best method to pass the query string 
> columndef, or better yet the tuple description, to the function. Any 
> suggestions on an approach?

Can't it get it for itself from the results of the query, ie, look at
PQftype() and so on to build a tupledesc?

I guess there are some gotchas with inconsistent type OIDs between
remote and local databases, but that still seems much less of a risk
than manual errors in giving the columnset definition.  You could at
least check that PQfsize matches the local type's typlen as a way of
detecting chance collisions of user-defined type OIDs.
        regards, tom lane

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> 
>>I'm trying to come up with the best method to pass the query string 
>>columndef, or better yet the tuple description, to the function. Any 
>>suggestions on an approach?
> 
> 
> Can't it get it for itself from the results of the query, ie, look at
> PQftype() and so on to build a tupledesc?

Hmm. Good point. That certainly works for dblink.

I guess most functions with need for anonymous composite types would be 
able to derive a tupdesc from libpq (dblink), SPI 
(tablefunc.c:crosstab), function arguments (tablefunc.c:crosstab), or it 
would be known in advance (guc.c:show_all_settings).

Can anyone think of a use case where the *only* source of tuple 
description would come from the query column def?


> I guess there are some gotchas with inconsistent type OIDs between
> remote and local databases, but that still seems much less of a risk
> than manual errors in giving the columnset definition.  You could at
> least check that PQfsize matches the local type's typlen as a way of
> detecting chance collisions of user-defined type OIDs.

Another good point.

Thanks!

Joe