Tom Lane wrote:
>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 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.
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