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

Reply via email to