Re: Using FDW AddForeignUpdateTargets for a hidden pseudo-column

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: 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 12:46:06
Message-ID: 1604F4E93D96BC049CF1FB4C@eje.land.credativ.lan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

--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.

--
Thanks

Bernd

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-06-14 12:46:15 Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Previous Message Robert Haas 2016-06-14 12:44:44 Re: Reviewing freeze map code