On Tue, Oct 1, 2013 at 10:19 AM, Magnus Hagander <mag...@hagander.net> wrote: >> If we can't feel comfortable with an ERROR, let's not do it at all. > > In principle, I agree. > > However, if we want to do this as a temporary measure to judge impact, > we could do WARNING now and flip it to ERROR in the next minor > release.
I can't imagine that whacking the behavior around multiple times is going to please very many people. And, from a practical standpoint, the time between minor releases is typically on the order of ~3 months. That's not very long. The situations in which trouble occurs are likely to obscure, and a lot of users don't apply every minor release, or don't apply them in a timely fashion. So I can't see that this strategy would increase our confidence very much anyway. In other words... > However, do we think we'll actually *get* any reports in of it if we > do that? As in would we trust the input? ...no. > If we do, the it might be > worth doing that. If we don't believe we'll get any input from the > WARNINGs anyway, we might as well flip it to an ERROR. But if we do > flip it to an ERROR, we should have a way to disable that error if, as > Alvaro puts it, we end up breaking too many things. A way of disabling the error seems like an awfully good idea. Since I know my audience, I won't suggest the obvious method of accomplishing that goal, but I think we all know what it is. -- 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