* ash (ash@commandprompt.com) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > 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
>
> That might be costly but not impossible. A user would need to do that
> anyway, though manually.
I was pointing out why it should need to be explicitly requested, but
all-in-all, I don't really see this proposal going anywhere. It's a
neat idea, and if there's a sensible way to do it, then the user should
have to explicitly request it, imv.
> > 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.
>
> I'm not suggesting that we try to *fix* functions, but if we can detect
> function breakage by re-parsing them it would be nice to alert the user
> of any problems at the instant of running ALTER TABLE statement, not
> when the user tries to actually run the function (see my mail upthread
> for sample scenario.)
We're not going to re-parse every function in the system, like, ever. I
might be willing to buy off on "too bad" in those cases (it's not like
we're going and fixing them today for ALTER TABLE .. TYPE cases anyway)
but the point is that cascading the change to a column's type through
all of its dependencies is likely to cause breakage somewhere in even
modestly complex systems and we shouldn't just start doing that
automatically.
Thanks,
Stephen