2013/12/5 Albe Laurenz <laurenz.a...@wien.gv.at>: > Ian Lawrence Barwick wrote: >> 2013/11/8 Tom Lane <t...@sss.pgh.pa.us>: >>> [ thinks for awhile... ] Hm. In principle you can put any expression >>> you want into the tlist during AddForeignUpdateTargets. However, if it's >>> not a Var then the planner won't understand that it's something that needs >>> to be supplied by the table scan, so things won't work right in any but >>> the most trivial cases (maybe not even then :-(). >>> >>> What I'd try is creating a Var that has the attno of ctid >>> (ie, SelfItemPointerAttributeNumber) but the datatype you want, ie bytea. >>> This won't match what the catalogs say your table's ctid is, but I think >>> that nothing will care much about that. >> >> Apologies for reinvigorating this thread, but I'm running into a similar wall >> myself and would like to clarify if this approach will work at all. >> >> My foreign data source is returning a fixed-length string as a unique row >> identifier; in AddForeignUpdateTargets() I can create a Var like this: >> >> var = makeVar(parsetree->resultRelation, >> SelfItemPointerAttributeNumber, >> BPCHAROID, >> 32, >> InvalidOid, >> 0); >> >> but is it possible to store something other than a TIDOID here, and if so >> how? > > Subsequent analysis showed that this won't work as you have > no way to populate such a resjunk column. > resjunk columns seem to get filled with the values from the > column of the same name, so currently there is no way to invent > your own column, fill it and pass it on. > > See thread 8b848b463a71b7a905bc5ef18b95528e.squir...@sq.gransy.com > > What I ended up doing is introduce a column option that identifies > a primary key column. I add a resjunk entry for each of those and > use them to identify the correct row during an UPDATE or DELETE. > > That only works for foreign data sources that have a concept of > a primary key, but maybe you can do something similar.
Thanks for confirming that, I suspected that might be the case. I'll have to go for Plan B (or C or D). Regards Ian Barwick -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
