Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw
Date
Msg-id CAFjFpRfxn1U9EGHNThz8qgVQXKFZoWcqaCdesU2PNuOcHKtBag@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Another oddity in handling of WCO constraints inpostgres_fdw  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Mar 13, 2018 at 8:34 PM, Stephen Frost <sfrost@snowman.net> wrote:
>
> It would really help to have some examples of exactly what is being
> proposed here wrt solutions.
>
> WCO is defined at a view level, so I'm not following the notion that
> we're going to depend on something remote to enforce the WCO when the
> remote object is just a regular table that you can't define a WCO on top
> of.  That's not the case when we're talking about foreign tables vs.
> local tables, so it's not the same.  I certainly don't think we should
> require a remote view to exist to perform the WCO check.  If the remote
> WCO is a view itself then I would expect it to operate in the same
> manner as WCO on local views does- you can have them defined as being
> cascaded or not.
>
> In other words, there is no case where we have a "foreign view."  Views
> are always local.  A "foreign table" could actually be a view, in which
> case everything we treat it as a table in the local database, but WCO
> doesn't come up in that case at all- there's no way to define WCO on a
> table, foreign or not.  If WCO is defined on the view on the remote
> server, then it should operate properly and not require anything from the
> local side.

I agree with this analysis. I have no objection about the patch anymore.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


pgsql-hackers by date:

Previous
From: Pavan Deolasee
Date:
Subject: Re: ON CONFLICT DO UPDATE for partitioned tables
Next
From: Ashutosh Bapat
Date:
Subject: Re: parallel append vs. simple UNION ALL