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

From Albe Laurenz
Subject Re: FDW: possible resjunk columns in AddForeignUpdateTargets
Date
Msg-id A737B7A37273E048B164557ADEF4A58B17C57B5B@ntex2010i.host.magwien.gv.at
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  (Tomas Vondra <tv@fuzzy.cz>)
List pgsql-hackers
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.

Yours,
Laurenz Albe

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.
Next
From: Heikki Linnakangas
Date:
Subject: Re: Gin page deletion bug