Tom Lane wrote: >> 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.
I was hoping for the latter (a hidden column). But I'll have to settle for primary keys, which is also ok. Thanks for taking the time. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers