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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
