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 12434.1401286213@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?  (ash <ash@commandprompt.com>)
Ответы Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Список pgsql-hackers
ash <ash@commandprompt.com> writes:
> Stephen Frost <sfrost@snowman.net> writes:
>> We're not going to re-parse every function in the system, like, ever.

> Well, only every *affected* function, which might be pretty minimal in
> the usual case.

We don't store dependency information for function bodies, so there's
no way to do this except by reparsing everything in sight.

A larger issue with the idea is that a function might fail reparsing
for reasons having nothing to do with the proposed ALTER TABLE.
For instance, it's not at all unusual for functions to contain references
to tables that don't normally exist, but are created when the function is
to be called (or maybe even by the function itself).  Because of this
problem, "reparsing", in the sense of detecting semantic rather than
purely syntactic problems in a function body, is something that we don't
actually do *at all*, ever, except when the function is actually executed.
(This is part of the reason why there's no dependency info.)
Pavel Stehule has made some efforts towards improving that situation
for plpgsql functions:
https://commitfest.postgresql.org/action/patch_view?id=884
but that patch remains pretty controversial and may never get committed.
Even if it does get in, it wouldn't move the goalposts for any other PL.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: pg_stat directory and pg_stat_statements
Следующее
От: David Fetter
Дата:
Сообщение: Re: IMPORT FOREIGN SCHEMA statement