Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> I've just started 9.3 beta testing and I noticed that a "simple" view
> defined on top of a writable foreign table is not automatically
> updatable.
> Given that these are both new-to-9.3 features, I think it would be a
> shame if they don't work together. It's basically a 1-line patch to
> make such views automatically updatable, plus a small extra code block
> in relation_is_updatable() to reflect the change in the
> information_schema views.
Meh. This is assuming that an FDW that defines, say, ExecForeignDelete
is thereby promising that *all* tables it supports are deletable. That
is not required by the current FDW API spec.
If we want to do something about this, I'd be a bit inclined to say that
we should add a new FDW callback function to let the FDW say whether
a particular rel is updatable or not.
I think it would be a good idea to get that done for 9.3, since all this
support is new in 9.3, and it's not too late to adjust the API now.
If we wait, there will be compatibility headaches.
> Specifically, for foreign tables
> information_schema.tables.is_insertable_into and
> information_schema.columns.is_updatable always say 'NO' even if the
> foreign table is writable. Fixing that would require new C functions
> along the same lines as pg_view_is_insertable/updatable(), or those
> functions could just be renamed and repurposed to do the check for all
> relation kinds, except those known to be always/never updatable.
I'd vote to rename/extend them to be pg_relation_is_updatable I think.
regards, tom lane
