Re: FDW: possible resjunk columns in AddForeignUpdateTargets - Mailing list pgsql-hackers

From Ian Lawrence Barwick
Subject Re: FDW: possible resjunk columns in AddForeignUpdateTargets
Date
Msg-id CAB8KJ=ipd-kiqpE6AGhRprSqj6TExm=Rx9+csH7HvuxLA=D8kw@mail.gmail.com
Whole thread Raw
In response to Re: FDW: possible resjunk columns in AddForeignUpdateTargets  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: FDW: possible resjunk columns in AddForeignUpdateTargets
List pgsql-hackers
2013/11/8 Tom Lane <tgl@sss.pgh.pa.us>:
> Albe Laurenz <laurenz.albe@wien.gv.at> writes:
>> What I would like to do is add a custom resjunk column
>> (e.g. a bytea) in AddForeignUpdateTargets that carries a row identifier
>> from the scan state to the modify state.
>> Would that be possible? Can I have anything else than a Var
>> in a resjunk column?
>
> [ 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?


Regards

Ian Barwick



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Extension Templates S03E11
Next
From: Pavel Stehule
Date:
Subject: Re: Problem with displaying "wide" tables in psql