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

  1. Allow CREATE OR REPLACE VIEW to add columns to the _end_ of the view.