On Tue, Jul 15, 2014 at 5:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Jul 15, 2014 at 10:20 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
