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
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 |