Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?
От | Stephen Frost |
---|---|
Тема | Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE? |
Дата | |
Msg-id | 20140602174032.GC2556@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Re-create dependent views on ALTER TABLE ALTER COLUMN
... TYPE?
Re: Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE? |
Список | pgsql-hackers |
* Robert Haas (robertmhaas@gmail.com) wrote: > On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > The real problem in my mind is one of user expectations. If the database > > silently does something behind your back, people expect that that action > > will be *right* and they don't have to worry about it. I don't think > > that automatically reparsing views has much chance of clearing that bar. [...] > >From a technical standpoint, I'm not very sure what to do to further > improve the situation - which I will broadly characterize as "view > dependency hell" - but if I did have such an idea I might be willing > to take a modest risk of user confusion if it seemed likely to also > reduce user frustration. Tom's point goes back to what I was trying to drive at originally- people should have to ask for this. Perhaps we can provide a way for them to ask which is explicit enough that they understand "this might not do exactly what you think it does", akin to what happens today with a drop-and-recreate-everything approach. 'CASCADE' might not be sufficient to meet that, maybe 'CASCADE REBUILD' or something? Of course, there is a question about if it's worth it to keep around the exact text of each CREATE VIEW and build all this infrastructure for something which will only work properly in a specific subset of cases and in many others could break silently, essentially installing a very handy looking foot-gun. Not sure I like that either. Thanks, Stephen
В списке pgsql-hackers по дате отправления: