On 2016/04/26 12:52, Robert Haas wrote:
On Mon, Apr 25, 2016 at 2:54 AM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
Thinking loudly:
This error is hard to interpret for a user who doesn't know about ctid. Till
we find a solution, we can at least fail gracefully with an error something
like "DMLs are not supported on foreign tables referring to views/non-tables
on foreign server" is not supported. While creating the foreign table a user
can specify whether the object being referred is updatable (writable?) or
not, Import foreign schema can set the status by looking at pg_class type
entry. The efforts required may not be worth the usage given that this case
is highly unlikely. May be we should just update the documents saying that a
user may encounter such an error if s/he attempts to update/delete such a
foreign table.
I would be disinclined to add code specifically to catch this, since
the only report we have so far is from someone whose job is to find
corner cases that break. Which he did, and good for him, but like you
say, that doesn't mean it's a big real-world problem. Adding a
sentence to the documentation stating that pointing a foreign table at
a view is fine for SELECT, but that UPDATE and DELETE may not work,
seems like enough.
+1 for just updating the documentation.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
