Hi all,
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?
Regards,
Aleksey