Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Date
Msg-id 18894.1401734877@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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.

Agreed.

> 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.

I think deparse-and-reparse is exactly what we have to do, mainly because,
if you subscribe to the idea that the user should see and approve semantic
changes, what else are we going to show her except SQL?  If she wants to
adjust the changes, it's even less plausible that the working
representation is not SQL text.  We might well produce the initial draft
form by manipulating the parsed querytree before deparsing, though.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Next
From: Hai Qian
Date:
Subject: Re: [GSoC] Clustering in MADlib - status update