On Sat, 2004-11-20 at 19:56, Joe Conway wrote:
> When returning "setof record", the column definition must exist in the
> query, and must match what ultimately is returned. This means that
> whatever logic you use in your application to write the sql statement
> must be able to derive the appropriate column types. That said, inside
> your function you have two choices (at least):
>
> -- you can directly determine the column definition used in the sql
> statement, as in dblink_record()
>
> /* get the requested return tuple description */
> tupdesc = CreateTupleDescCopy(rsinfo->expectedDesc);
>
Actually I use the code of dblink_record() to execute queries on remote
sites! The thing is that I want either to avoid giving the column types
in startup (I don't think this is possible) OR (preferred and possible,
I suppose) to BYPASS this mechanism by providing another tupdesc
"object" referring to the executed query (as I said this NOT always the
query provided on function call). This would be something like:
tupdesc = CreateTupleDescCopy(my_tupdesc);
> -- you can use the same logic that your application did to derive
> the column desc and build it yourself, similar to
> make_crosstab_tupledesc() in contrib/tablefunc
>
If this query is executed using SPI calls then this function shows
exactly what I need.But what happends if the query is to be executed
using PQexec() like functions, that is in my case a call to a remote db?
In this case, is there any mechanism that could help retrieve the
tupdesc for this query? I may end up providing different results than
those expected from the original query. An idea was to make a
pg_attribute query to fill the Form_pg_attribute array of the my_tupdesc
but I don't think this is enough (what about TupleConstr *constr, and
aggregate results). Another idea was to parse the Query node (available
for the executed query) and fill this array (again what about
TupleConstr *constr?).
> > Second, could you please tell me where in the code an incoming
> > request, from a remote dblink_record() call, is handled? I'm a little
> > lost here :-)
> I don't understand what you're asking here. Can you elaborate?
This is topic I just started to study so excuse me if I I'm not so
clear:-). What I'm asking is: what is the mechanism that handles
incoming requests (from remote nodes). Which module listens on port 5432
(I think this is it...) for calls from other computers? Which modules
take the incoming query (execute it and) put the results on wire? I just
need a pointer.
Thanks,
Ntinos Katsaros
