* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, May 26, 2014 at 10:39 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > It'd need to be explicitly requested, eg a 'CASCADE' option.
>
> Why? Would any sane person NOT want this behavior?
[...]
> Now maybe there are options other than trying to reproduce what the
> original CREATE OR REPLACE statement would have done against the new
> type. For example, we could look through views that depend on t.a and
> rewrite each reference to that column to t.a::oldtype. This might
> lead to odd results with multiple nested casts and generally funny
> behavior if the column is re-typed multiple times; but maybe there's
> some way to fix that.
This.
> Also, it might not really be the semantics you
> want if you were hoping the type update would truly cascade. But it
> might still be better than a sharp stick in the eye, which is kinda
> what we offer today.
I hadn't even considered the idea that we would go through and try to
change everything which referenced that view to now be the new type- but
in that case, I'd want to know that there were other changes which were
happening beyond the single view which I was updating. Perhaps a NOTICE
would be enough, but it doesn't feel correct to me. Also consider
MatViews which would need to be rewritten for the new type, or pl/pgsql
functions which we couldn't possibly fix entirely (we're going to change
the variable's type definition because it selects out a column from this
view?) and so they'd just break instead.
Thanks,
Stephen
