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