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 12434.1401286213@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?  (ash <ash@commandprompt.com>)
Responses Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?  (ash <ash@commandprompt.com>)
List 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 by date:

Previous
From: Fujii Masao
Date:
Subject: pg_stat directory and pg_stat_statements
Next
From: David Fetter
Date:
Subject: Re: IMPORT FOREIGN SCHEMA statement