Re: writable FDWs / update targets confusion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Cc: Tomas Vondra *EXTERN* <tv(at)fuzzy(dot)cz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: writable FDWs / update targets confusion
Date: 2013-11-15 17:31:40
Message-ID: 28029.1384536700@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> writes:
> Tom, could you show us a rope if there is one?

What is it you actually need to fetch?

IIRC, the idea was that most FDWs would do the equivalent of fetching the
primary-key columns to use in an update. If that's what you need, then
AddForeignUpdateTargets should identify those columns and generate Vars
for them. postgres_fdw is probably not a good model since it's using
ctid (a non-portable thing) and piggybacking on the existence of a tuple
header field to put that in.

If you're dealing with some sort of hidden tuple identity column that
works like CTID but doesn't fit in six bytes, there may not be any good
solution in the current state of the FDW support. As I mentioned, we'd
batted around the idea of letting FDWs define a system column with some
other datatype besides TID, but we'd not figured out all the nitty
gritty details in time for 9.3.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yeb Havinga 2013-11-15 17:32:43 Re: Transaction-lifespan memory leak with plpgsql DO blocks
Previous Message Alexander Korotkov 2013-11-15 17:24:25 Re: GIN improvements part 1: additional information