Re: writable FDWs / update targets confusion

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-18 08:28:31
Message-ID: A737B7A37273E048B164557ADEF4A58B17C5A9BF@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>> 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.

I was hoping for the latter (a hidden column).

But I'll have to settle for primary keys, which is also ok.

Thanks for taking the time.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-11-18 08:32:46 Re: freeze cannot be finished
Previous Message David Rowley 2013-11-18 08:22:58 Re: CLUSTER FREEZE