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