Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE? - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
Date
Msg-id 20140603065139.GD10580@svana.org
Whole thread Raw
In response to Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Jun 02, 2014 at 01:29:25PM -0400, Robert Haas wrote:
> I agree, but I think it's important to note that Alex's complaint is
> not unique - the way things work now is a real source of frustration
> for users.  In a previous job, I wrote a schema-upgrade script that
> dropped all of the views in reverse creation order, applied the schema
> updates, and then recreated all the views. This worked, but it was a
> lot of hassle that I would have preferred to avoid, and in a
> higher-volume application, simultaneously grabbing exclusive locks on
> a large number of critical views would have been a non-starter.  In
> the job before that, I did the same thing manually, which was no fun
> at all.  This was actually what posted me to write one of my first
> patches, committed by Bruce as
> ff1ea2173a92dea975d399a4ca25723f83762e55.

Would it be sufficient to automatically pass the type change through
only if nothing in the view actually references it in a function,
operator, group by, order by, etc?  That is, it only appears in the
SELECT list unadorned?  Or is that too limiting?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.  -- Arthur Schopenhauer

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Spreading full-page writes
Next
From: Peter Geoghegan
Date:
Subject: Re: 9.4 release notes