* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, May 26, 2014 at 10:39 AM, Stephen Frost <sfr...@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
Description: Digital signature