Re: returning SETOF RECORD - Mailing list pgsql-hackers

From Tom Lane
Subject Re: returning SETOF RECORD
Date
Msg-id 12560.1405460131@sss.pgh.pa.us
Whole thread Raw
In response to Re: returning SETOF RECORD  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: returning SETOF RECORD  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 15, 2014 at 10:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think you're confusing these functions with the kind that specify
>> their own output rowtype --- which we *can* handle, via a list of OUT
>> parameters.  In these cases, the entire point is that the user has to
>> specify what SQL rowtype he wants out of the conversion.

> Actually, on further study, I found that isn't quite true.  dblink()'s
> materializeResult() calls CreateTemplateTupleDesc() if the query
> returns PGRES_COMMAND_OK and get_call_result_type() only if it returns
> PGRES_TUPLES_OK.

Right --- in the command case, dblink acts like a function that does know
its output rowtype.  None too consistent.

We could imagine allowing dblink to default to an output rowtype of
"(text,text,...)" if it can't get anything from its call environment.
I'm not sure if that would be an improvement or not.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Reset master xmin when hot_standby_feedback disabled.
Next
From: Tom Lane
Date:
Subject: Upcoming back-branch releases