Re: [9.3] Automatically updatable views vs writable foreign tables

looking at this patch some more ...

Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> One place where I think we have diverged from the spec, however, is in
> information_schema.columns.updatable. This should be returning 'YES'
> if the individual column is updatable, and I see no reason for that
> the require the relation to support DELETE, which is what we currently
> do (and always have done).

I'm not convinced about this change.  The spec's notion of updatability
requires both UPDATE and DELETE to be allowed; that's why they don't
have a separate is_deletable attribute.  And they don't have any such
thing as a column whose updatability doesn't require updatability of the
underlying table.  So I think the previous behavior was correct and
should be maintained: although Postgres does permit decoupling
deletability from updatability, only tables/columns for which both
operations are possible should be marked is_updatable in the
information_schema.  Otherwise, an application relying on the assumption
that "is_updatable" means it can DELETE will be broken.

I can see however that varying opinions on this are possible.  Although
I'd removed the separate pg_column_is_updatable() function from your
patch with the intent of using pg_relation_is_updatable() directly,
I'm now thinking about putting back the former, so that this decision
is taken in C code where we can change it without an initdb.
        regards, tom lane