There was discussion about altering type, mostly about changing beween binary incompatible types (e.g. int4->numeric) requiring adding/dropping columns and deep recreation of dependent objects.It doesn't fix views that contain references to the column. The new typmod would need to be propagated into the view's rule parsetree, and perhaps to the type of the view's result column if the view directly exposes the changed column (whereupon you need to recursively look at the views that depend on this one, etc).
What you could probably do is find the referencing views via pg_depend. For each one, try to do CREATE OR REPLACE VIEW using the view definition string from pg_get_viewdef. If it succeeds you're done (the variable must not be propagated to any output column). If it fails, adjust the indicated output column's typmod. Lather, rinse, repeat in case there is more than one dependent output column. Recurse once you've successfully altered the view.
It'd probably also be a smart idea to error out if pg_depend shows any dependencies on the column from objects that you don't know what to do with (aren't views).
I recall there was some discussion of this stuff on pgsql-hackers the last time it was proposed to support "ALTER COLUMN type". We may have thought of some additional considerations besides views. I'd suggest trawling the list archives to see...
There was a thread stating that a limited class of changes exist that can be done without deep impact, namely changing between binary compatible types and extending the length. This is what pgadmin3 does, but apparently this wasn't correct.
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
