Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
От | Martijn van Oosterhout |
---|---|
Тема | Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE? |
Дата | |
Msg-id | 20140603065139.GD10580@svana.org обсуждение исходный текст |
Ответ на | Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE? (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: