Katsaros Kwn/nos wrote:
Either set it to:  "setof  _some_predifined_type" or set it to:
"setof records" and then define the expected results with "as(attr1
type, ..., attr_n type)".

Right?

Correct. Except it should be "setof record", not "setof records".


If these are indeed the only ways, is it possible to write an SRF
whose return type is defined inside the code (something like the
second way mentioned above but altering TupleDesc or something like
that?) based on the executed query? What I want to do is to write an
SRF, which will execute a query maybe different than (but derived
from) the original one passed to this function. Obviously the first
way is not suitable since I cannot know a priori (before entering my
SRF) what the result type will exactly be.

If I understand correctly what you are asking, the answer is yes ;-)

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);

 -- 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

    (see line 1636 in cvs HEAD sources)


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?

Joe

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to