On 18.11.2013 09:28, Albe Laurenz wrote:
> 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.
I was hoping for the latter too, and I can't really switch to primary
key columns. I can live with 6B passed in the ctid field for now, but
it'd be nice to be able to use at least 8B.
I think that we should make the documentation more explicit about this
limitation, because the current wording in fdw-callbacks documentation
seems to suggest it's possible to add such hidden columns. At least
that's how I read it before running into this.
regards
Tomas