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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Дата
Msg-id 18894.1401734877@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Следующее
От: Hai Qian
Дата:
Сообщение: Re: [GSoC] Clustering in MADlib - status update