Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Alex Shulgin <ash@commandprompt.com>
From: ash <ash@commandprompt.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>,
"pgsql-hackers\@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2014-05-28T15:47:59Z
Lists: pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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
Commits
-
Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view.
- ff1ea2173a92 8.4.0 cited