On Tue, Jul 15, 2014 at 5:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Well, right now, it doesn't seem like it would buy much. If some of
the cases I showed failing in the previous email could be made to
actually do something useful, then it'd be more worthwhile.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
