Date: Mon, 22 Apr 2019 13:27:03 -0700
From: Andres Freund <andres@anarazel.de>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>,
	Robert Haas <rhaas@postgresql.org>,
	pgsql-committers@lists.postgresql.org,
	pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Allow insert and update tuple routing and COPY for
 foreign table
Message-ID: <20190422202703.4mgtqv3mqtamsgel@alap3.anarazel.de>
References: <E1f4aif-0004qo-A6@gemulon.postgresql.org>
 <ed0b7471dce91169d871347cf003d8094ab96895.camel@cybertec.at>
 <5CBDB770.2060602@lab.ntt.co.jp>
 <b459d1b1b4eb8c0d538a2c5b70e131af3c391954.camel@cybertec.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b459d1b1b4eb8c0d538a2c5b70e131af3c391954.camel@cybertec.at>
Precedence: bulk

Hi,

On 2019-04-22 21:37:25 +0200, Laurenz Albe wrote:
> Subject: [PATCH] Foreign table COPY FROM and tuple routing requires
>  BeginForeignInsert
> 
> Commit 3d956d956a introduced support for foreign tables as partitions
> and COPY FROM on foreign tables.
> 
> If a foreign data wrapper supports data modifications, but either has
> not adapted to this change yet or doesn't want to support it
> for other reasons, it probably got broken by the above commit,
> because COPY will just call ExecForeignInsert anyway, which might not
> work because neither PlanForeignModify nor BeginForeignModify have
> been called.
> 
> To avoid breaking third-party foreign data wrappers in that way, allow
> COPY FROM and tuple routing for foreign tables only if the foreign data
> wrapper implements BeginForeignInsert.

Isn't this worse though? Before this it's an API change between major
versions. With this it's an API change in a *minor* version. Sure, it's
one that doesn't crash, but it's still a pretty substantial function
regression, no?

Greetings,

Andres Freund