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

From Tomas Vondra
Subject Re: FDW: possible resjunk columns in AddForeignUpdateTargets
Date
Msg-id 5282BF21.3020202@fuzzy.cz
Whole thread Raw
In response to Re: FDW: possible resjunk columns in AddForeignUpdateTargets  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Responses Re: FDW: possible resjunk columns in AddForeignUpdateTargets  (Albe Laurenz <laurenz.albe@wien.gv.at>)
List pgsql-hackers
On 8.11.2013 16:13, Albe Laurenz wrote:
> Tom Lane wrote:
>> 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.
>> 
>> It's definitely an area that could use more work.  IIRC we'd
>> discussed providing some way for an FDW to specify the type of the
>> ctid column for its tables, but we didn't do anything about it in
>> 9.3.
> 
> Thanks a lot, I will try that.

Hi Laurenz,

have you found a way to pass data types other than TID as a resjunk
column? I'm trying to solve almost the same thing (pass INT8 instead of
TID), but I got stuck.

Adding a custom Var with INT8OID instead of TIDOID seems to work fine,
but I've found no way to populate this in IterateForeignScan :-(

regards
Tomas



pgsql-hackers by date:

Previous
From: Jeffrey Walton
Date:
Subject: Re: Clang 3.3 Analyzer Results
Next
From: Andreas
Date:
Subject: Re: Relax table alias conflict rule in 9.3?