Re: alter server for foreign table

From: konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Derry Hamilton <rasilon(dot)x(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: alter server for foreign table
Date: 2017-09-30 20:29:00
Message-ID: F5354165-1482-46A3-B279-1E4A2A130239@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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...

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-09-30 21:03:13 Re: Causal reads take II
Previous Message Nico Williams 2017-09-30 20:26:54 Re: alter server for foreign table