| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FDW for PostgreSQL |
| Date: | 2013-02-21 15:21:34 |
| Message-ID: | 25883.1361460094@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-02-21 09:58:57 -0500, Tom Lane wrote:
>> How exactly would it do that via an FDW? Surely if the user tries to
>> execute INSERT/UPDATE/DELETE against a foreign table, the command would
>> get rejected in a read-only transaction, long before we even figure out
>> that the target is a foreign table?
> I was thinking of querying a remote table thats actually a view. Which
> might be using a function that does caching into a table or something.
> Not a completely unreasonable design.
Yeah, referencing a remote view is something that should work fine, but
it's not clear to me why it should work differently than it does on the
remote server. If you select from that same view in a READ ONLY
transaction on the remote, won't it fail? If so, why should that work
if it's selected from via a foreign table?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-02-21 15:25:57 | Re: FDW for PostgreSQL |
| Previous Message | Andres Freund | 2013-02-21 15:19:57 | Re: Materialized views WIP patch |