From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw |
Date: | 2018-03-13 15:04:09 |
Message-ID: | 20180313150409.GZ2416@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Ashutosh Bapat (ashutosh(dot)bapat(at)enterprisedb(dot)com) wrote:
> On Mon, Mar 12, 2018 at 1:25 PM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > (2018/03/09 20:55), Etsuro Fujita wrote:
> >> (2018/03/08 14:24), Ashutosh Bapat wrote:
> >>> For local constraints to be enforced, we use remote
> >>> constraints. For local WCO we need to use remote WCO. That means we
> >>> create many foreign tables pointing to same local table on the foreign
> >>> server through many views, but it's not impossible.
> >>
> >> Maybe I don't understand this correctly, but I guess that it would be
> >> the user's responsibility to not create foreign tables in such a way.
> >
> > I think I misunderstood your words. Sorry for that. I think what you
> > proposed would be a solution for this issue, but I'm not sure that's a good
> > one because that wouldn't work for the data sources that don't support views
> > with WCO options.
>
> Our solution for the constraints doesn't work with the data sources
> (like flat files) which don't support constraints. So, that argument
> doesn't help.
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.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-03-13 15:08:36 | Re: committing inside cursor loop |
Previous Message | Andrey Borodin | 2018-03-13 15:02:36 | Re: Google Summer of Code: Potential Applicant |