On Fri, Jun 1, 2018 at 7:43 AM, Kyotaro HORIGUCHI
<kyota.horiguchi@gmail.com> wrote:
> On Thu, May 31, 2018 at 11:34 AM, Ashutosh Bapat
> <ashutosh.bapat@enterprisedb.com> wrote:
>> On Thu, May 31, 2018 at 7:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> What you want for the first part of that is basically like
>>> generate_new_param() in subselect.c. We don't expose that publicly
>>> at the moment, but we could, or maybe better to invent another wrapper
>>> around it like SS_make_initplan_output_param.
>>
>> This looks like a lot of change which might take some time and may not
>
> I agree. It needs at least, in a short sight, an additional parameter
> (PlannerInfo in a straightforwad way) for
> postgresAddForeignUpdateTargets which is a change of FDW-API.
>
>> be back-portable. In the mean time, can we see if 0001 and 0002
>> patches are good and apply them. Those patches intend to stop the
>> multiple rows on the foreign server being updated by throwing error
>> (and aborting the transaction on the foreign server) when that
>> happens. That will at least avoid silent corruption that happens today
>> and should be back-portable.
>>
>> [1] https://www.postgresql.org/message-id/CAFjFpRfK69ptCTNChBBk+LYMXFzJ92SW6NmG4HLn_1y7xFk=kw@mail.gmail.com
>
> Having said that I think that storing oids of the remote table in
> local tableoid syscolumn is a breakage of the existing contract about
> the field. (I wish this is comprehensible.)
> However I haven't found a way to "fix" this without such breakage of
> API thus it seems to me inevitable to leave this problem as a
> restriction, we still can avoid the problematic behavior by explicitly
> declaring remote tableoid column (like the "key" column option of
> oracle-fdw).
>
> CREATE FOREIGN TABLE ft1 (rtoid oid, a int, blah, blah) SERVER sv
> OPTIONS (remote_tableoid 'rtoid', table_name 'lt1');
>
> However, of-course the proposed fix will work if we allow the
> a-kind-of illegal usage of the local tableoid. And it seems to be a
> way to cause a series of frequent changes on the same feature.
>
> Thoughts?
I am not suggesting to commit 0003 in my patch set, but just 0001 and
0002 which just raise an error when multiple rows get updated when
only one row is expected to be updated.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company