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

From: ash <ash(at)commandprompt(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers\(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Date: 2014-05-28 13:38:45
Message-ID: 87vbsqgh0a.fsf@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Stephen Frost <sfrost(at)snowman(dot)net> writes:

> * ash (ash(at)commandprompt(dot)com) wrote:
>> Stephen Frost <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-05-28 13:46:44 Re: pg_llog not mentioned in "Database File Layout"
Previous Message Stephen Frost 2014-05-28 13:02:11 Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?