Re: Using FDW AddForeignUpdateTargets for a hidden pseudo-column

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "'Aleksey Demakov *EXTERN*'" <a(dot)demakov(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using FDW AddForeignUpdateTargets for a hidden pseudo-column
Date: 2016-06-14 13:40:36
Message-ID: 22998.1465911636@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bernd Helmle <mailings(at)oopsware(dot)de> writes:
> --On 14. Juni 2016 10:32:13 +0000 Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
> wrote:
>> I first thought of using the internal ROWID column that's probably
>> similar to your case, but that wouldn't fit into a tid's 6 bytes, and I
>> found that I could only add resjunk columns for existing columns of the
>> table.
>> Making the internal ROWID an explicit column in the foreign table seemed
>> just too ugly.

> The Informix FDW uses SelfItemPointerAttributeNumber. Luckily the Informix
> ROWID is a 4 byte encoded identifier (3 first significant bytes are the
> logical page number, last significant bytes is the slot number within that
> page). Maybe you can find a way of logically addressing your data, too? It
> only needs to fit within 6 bytes, afaik.

There's been some speculation about allowing FDWs to control the type of
the CTID column created for a foreign table, but it hasn't gotten past
the speculation stage yet.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-06-14 14:48:20 Re: Use of CREATE OR REPLACE in bloom--1.0.sql
Previous Message Aleksey Demakov 2016-06-14 13:27:05 Re: Using FDW AddForeignUpdateTargets for a hidden pseudo-column