Simon Riggs <simon@2ndQuadrant.com> writes:
> On 9 December 2012 22:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> But in any case, those functions are expensive enough that I can't see
>> running them against every view in the DB anytime somebody hits tab.
>> I think just allowing tab-completion to include all views is probably
>> the best compromise.
> I'm surprised to see that "updateable" and "trigger updateable" states
> aren't recorded in the catalog somewhere. ISTM a useful thing to be
> able to know about a view and not something we should be calculating
> on the fly. That has nothing much to do with tab completion, it just
> seems like a generally useful thing.
No, I don't find that a useful idea. These things are not that
expensive to check given that you have an open relcache entry to look
at, which would be the case anywhere in the backend that we wanted to
know them. The reason that running the functions in a tab-completion
query looks unpleasant is that it'd imply opening (and probably locking)
a large number of views.
If we did put an "updatable" flag into the catalogs then (1) we'd be
giving up the ability to change the updatability conditions without an
initdb, and (2) we'd have a problem with updating the flag for
referencing views when a referenced view changed its state.
regards, tom lane