On 2013-02-21 10:21:34 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.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?
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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
