Re: returning SETOF RECORD

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: returning SETOF RECORD
Date: 2014-07-15 21:35:31
Message-ID: 12560.1405460131@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jul 15, 2014 at 10:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-07-15 21:45:52 Upcoming back-branch releases
Previous Message Tom Lane 2014-07-15 21:24:37 Re: [COMMITTERS] pgsql: Reset master xmin when hot_standby_feedback disabled.