Albe Laurenz <laurenz.a...@wien.gv.at> writes:
> Tom, could you show us a rope if there is one?
What is it you actually need to fetch?
IIRC, the idea was that most FDWs would do the equivalent of fetching the
primary-key columns to use in an update. If that's what you need, then
AddForeignUpdateTargets should identify those columns and generate Vars
for them. postgres_fdw is probably not a good model since it's using
ctid (a non-portable thing) and piggybacking on the existence of a tuple
header field to put that in.
If you're dealing with some sort of hidden tuple identity column that
works like CTID but doesn't fit in six bytes, there may not be any good
solution in the current state of the FDW support. As I mentioned, we'd
batted around the idea of letting FDWs define a system column with some
other datatype besides TID, but we'd not figured out all the nitty
gritty details in time for 9.3.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
