looking at this patch some more ...
Dean Rasheed <dean.a.rash...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
