From: | ash <ash(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(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-05-28 15:47:59 |
Message-ID: | 87oayhhplc.fsf@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> 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.
OK, forget functions, I now realize it's not feasible to consider.
Can we get back to re-defining views at least?
--
Alex
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-05-28 16:19:03 | Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE? |
Previous Message | Peter Geoghegan | 2014-05-28 15:37:50 | Re: pg_stat directory and pg_stat_statements |