On Mon, Jun 2, 2014 at 10:21 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Jun 2, 2014 at 8:52 AM, ash <a...@commandprompt.com> wrote: >>> Should this fail, the user will have to work around it, but most of the >>> time it could just work. > >> You're either missing or choosing to ignore the point that I'm making, >> which is that we *don't have* the text form of the view anywhere. > > Even if we did, I don't think it'd affect this decision. > > 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.
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. >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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
