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  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Odd procedure resolution
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Removing unneeded self joins