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

From Tom Lane
Subject Re: FDW: possible resjunk columns in AddForeignUpdateTargets
Date
Msg-id 28093.1383922665@sss.pgh.pa.us
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>)
Re: FDW: possible resjunk columns in AddForeignUpdateTargets  (Ian Lawrence Barwick <barwick@gmail.com>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: FDW: possible resjunk columns in AddForeignUpdateTargets
Next
From: Nigel Heron
Date:
Subject: Re: stats for network traffic WIP