Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?

Stephen Frost <sfrost@snowman.net> writes:

> * ash (ash@commandprompt.com) wrote:
>> Stephen Frost <sfrost@snowman.net> writes:
>> 
>> > 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.

Ah, understood.

>> > 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.

Well, only every *affected* function, which might be pretty minimal in
the usual case.

> 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.

What I am suggesting is that we try to detect such breakage at the time
the user runs ALTER TABLE (issuing NOTICE or ERROR at user discretion.)
If changing column type of a table breaks some functions down the way,
the user will hit it anyway, but better know it soon than when he wants
to *run* that function.

--
Alex