| 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:30:52 |
| Message-ID: | 26146.1361460652@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:
> Sure, it might fail if you use READ ONLY explicitly. Or the code might
> check it. The point is that one might not have choice about the READ
> ONLY state of the local transaction if its a HS standby as all
> transactions are READ ONLY there.
[ shrug... ] If you want to use a remote DB to cheat on READ ONLY,
there's always dblink. It's not apparent to me that the FDW
implementation should try to be complicit in such cheating.
(Not that it would work anyway given the command-level checks.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2013-02-21 15:35:58 | Re: Materialized views WIP patch |
| Previous Message | Kevin Grittner | 2013-02-21 15:26:06 | Re: Materialized views WIP patch |