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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers