From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.3] writable foreign tables |
Date: | 2013-03-10 21:53:00 |
Message-ID: | 12448.1362952380@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Excellent news. But I noticed as I went to update my non-writeable FDW
> that this has happened in the regression tests. Is this correct?
Yeah, see the adjustment I made in the file_fdw test (which that looks
to be borrowed from).
The new theory is that SELECT FOR UPDATE is allowed on foreign tables,
and if the FDW doesn't do anything to implement it, it's just a no-op.
I looked into having the core code throw an error, but it was a pain
in the rear and of dubious merit anyway (since you can't really tell
for sure from outside the FDW whether the FDW did anything or whether
there's even any need to do anything for the particular data source).
Besides, the old behavior was less than consistent, since it only
complained when the FOR UPDATE directly mentioned the foreign table,
though that's not what the semantics are supposed to be.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-03-10 22:01:59 | Re: [v9.3] writable foreign tables |
Previous Message | Thom Brown | 2013-03-10 20:55:28 | Re: [v9.3] writable foreign tables |