Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
