On Fri, Oct 25, 2019 at 12:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> end of things. And allowing arbitrary queries to go over a postgres_fdw
> connection would be absolutely disastrous from a debuggability and
> maintainability standpoint, because they might change the remote
> session's state in ways that postgres_fdw isn't prepared to handle.
> (In a dblink connection, the remote session's state is the user's
> responsibility to manage, but this isn't the case for postgres_fdw.)
> So I think this proposal has to be firmly rejected.
I think the reduction in debuggability and maintainability has to be
balanced against a possible significant gain in usability. I mean,
you could document that if the values of certain GUCs are changed, or
if you create and drop prepared statements with certain names, it
might cause queries in the same session issued through the regular
foreign table API to produce wrong answers. That would still leave an
enormous number of queries that users could issue with absolutely no
problems. I really don't see a bona fide maintainability problem here.
When someone produces a reproducible test case showing that they did
one of the things we told them not to do, then we'll tell them to read
the fine manual and move on.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
