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