On Sep 30, 2017, at 10:58 PM, Andrew Dunstan wrote: > > > On 09/30/2017 05:14 AM, Derry Hamilton wrote: >> Just to say, yes, this would be handy. I've been using a variant of >> that hack on reporting servers, while migrating systems from >> proprietary databases. It behaves quite gracefully when there are >> incompatible options, and it fixes up properly with DROPs as the first >> options. >> >> > > > I assume the proposal is to allow changing to a different server using > the same FDW. I can see all sorts of odd things happening if we allow > changing to a server of a different FDW.
Actually what I need is to handle a move of a shard (partition) to other node. I can not use "alter server" to change connection string, because this server is used for many shards located at this node. And I do not want to drop and recreate foreign table because it seems to be very complicated. So I need to change server of the same FDW. But in theory I can imagine situation when partition is moved to another database (from MySQL to Postgres for example). In this case we need to change FDW. What can be wrong with changing FDW? All checks that FDW is consistent with foreign table can be redone... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
