On Fri, Oct 25, 2019 at 12:38 PM Tom Lane <t...@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
