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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, ash <ash(at)commandprompt(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Date: 2014-06-02 18:47:57
Message-ID: 18894.1401734877@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2014-06-02 21:49:37 Re: Proposing pg_hibernate
Previous Message Tom Lane 2014-06-02 18:42:17 Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?