From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: anonymous composite types - how to pass tupdesc to |
Date: | 2002-08-26 19:52:13 |
Message-ID: | 3D6A86ED.7040808@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-08-26 19:54:48 | Re: LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1? |
Previous Message | Magnus Enbom | 2002-08-26 19:50:27 | Re: LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1? |