From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "'Aleksey Demakov *EXTERN*'" <a(dot)demakov(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using FDW AddForeignUpdateTargets for a hidden pseudo-column |
Date: | 2016-06-14 10:32:13 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B53860913@ntex2010i.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aleksey Demakov wrote:
> I have a data store where tuples have unique identities that normally are not visible.
> I also have a FDW to work with this data store. As per the docs to implement updates
> for this data store I have AddForeignUpdateTargets() function that adds an artificial
> column to the target list.
>
> It seems to me that I cannot re-use a system attribute number for this artificial resjunk
> column (as, for instance, postgres_fdw uses SelfItemPointerAttributeNumber). These
> attributes have specific meaning not compatible with my tuple identity.
>
> On other hand using a regular AttrNumber might confuse the query planner. In contrast
> e..g with Oracle FDW that can use a unique key to identify the row, in my data store
> the tuple identity is normally not visible. So the data planner might break if it sees a
> Var node with an unexpected varattno number.
>
> What is the best approach to handle such a case?
>
> 1. Give up on this entirely and require a unique key for any table used thru FDW.
>
> 2. Force the FDW to expose the identity column either explicitly by the user who
> creates a foreign table or automatically adding it in the corresponding trigger
> (preferably still making it hidden for normal scans).
>
> 3. Modify the postgresql core to nicely handle the case of an unknown target
> column added by a FDW.
>
> 4. Something else?
When implementing this for oracle_fdw, I went with your solution #1.
The downside is that anything that does not have a unique key cannot be
modified.
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.
I don't know if #3 would be difficult, but it sure would make things easier
for FDW developers.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Karlsson | 2016-06-14 10:37:18 | Re: Parallel safety tagging of extension functions |
Previous Message | Aleksey Demakov | 2016-06-14 10:02:57 | Using FDW AddForeignUpdateTargets for a hidden pseudo-column |