Re: [HACKERS] Another oddity in handling of WCO constraints inpostgres_fdw
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] Another oddity in handling of WCO constraints inpostgres_fdw |
Дата | |
Msg-id | 20180313150409.GZ2416@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw
|
Список | pgsql-hackers |
Greetings, * Ashutosh Bapat (ashutosh.bapat@enterprisedb.com) wrote: > On Mon, Mar 12, 2018 at 1:25 PM, Etsuro Fujita > <fujita.etsuro@lab.ntt.co.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
Вложения
В списке pgsql-hackers по дате отправления: