Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server
От | Robert Haas |
---|---|
Тема | Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server |
Дата | |
Msg-id | CA+TgmoaBuzhhcA21sAm7wH+A-GH2d6GkKhVapkqhnHOW85dDXg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Problem while updating a foreign table pointing to apartitioned table on foreign server (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Problem while updating a foreign table pointing to apartitioned table on foreign server
|
Список | pgsql-hackers |
On Fri, May 18, 2018 at 4:29 AM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > I have reached to the same thought. > > The point here is that it is a base relation, which is not > assumed to have additional columns not in its definition, > including nonsystem junk columns. I'm not sure but it seems not > that simple to give base relations an ability to have junk > columns. Do you know where that assumption is embedded specifically? If you're correct, then the FDW API is and always has been broken by design for any remote data source that uses a row identifier other than CTID, unless every foreign table definition always includes the row identifier as an explicit column. I might be wrong here, but I'm pretty sure Tom wouldn't have committed this API in the first place with such a glaring hole in the design. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: