Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

On Mon, Jun 2, 2014 at 1:40 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > The real problem in my mind is one of user expectations. If the database
>> > silently does something behind your back, people expect that that action
>> > will be *right* and they don't have to worry about it. I don't think
>> > that automatically reparsing views has much chance of clearing that bar.
> [...]
>> >From a technical standpoint, I'm not very sure what to do to further
>> improve the situation - which I will broadly characterize as "view
>> dependency hell" - but if I did have such an idea I might be willing
>> to take a modest risk of user confusion if it seemed likely to also
>> reduce user frustration.
>
> Tom's point goes back to what I was trying to drive at originally-
> people should have to ask for this.

Well, my point is that we don't yet know what "this" is, so trying to
decide on whether users should be forced to request it or in exactly
what manner seems like putting the cart before the horse. We may well
need some syntax, but it's too soon to decide what it is.

FWIW, I don't think reparsing the original view-text is even remotely
plausible. The fact that views stay glued to the same objects even of
those objects are renamed is a pretty handy property of the current
system, and any sort of reparse-from-scratch technique would give that
up. Deparse-and-reparse might be better, but I'll bet that has too
many problems to be viable, too (even if I haven't yet thought of what
they are). For better or for worse, I think the best we're likely to
be able to do is somehow manipulate the already-parsed rewrite rule.
I don't have any great ideas about how to do that, either, but it
seems less problematic than going back to the SQL representation.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company