Re: Second thoughts on CheckIndexCompatible() vs. operator families
От | Robert Haas |
---|---|
Тема | Re: Second thoughts on CheckIndexCompatible() vs. operator families |
Дата | |
Msg-id | CA+Tgmob-mg7WngDk2duvYuGy7Wkwd8mjLMSicwL8ebGSuBfecA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Second thoughts on CheckIndexCompatible() vs. operator families (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Second thoughts on CheckIndexCompatible() vs.
operator families
|
Список | pgsql-hackers |
On Thu, Jan 26, 2012 at 6:55 AM, Noah Misch <noah@leadboat.com> wrote: > On Wed, Jan 25, 2012 at 11:53:10PM -0500, Tom Lane wrote: >> Not only is that code spectacularly unreadable, but has nobody noticed >> that this commit broke the buildfarm? > > Thanks for reporting the problem. This arose because the new test case > temporarily sets client_min_messages=DEBUG1. The default buildfarm > configuration sets log_statement=all in its postgresql.conf, so the client > gets those log_statement lines. I would fix this as attached, resetting the > optional logging to defaults during the test cases in question. Not > delightful, but that's what we have to work with. I'm just going to remove the test. This is not very future-proof and an ugly pattern if it gets copied to other places. We need to work on a more sensible way for ALTER TABLE to report what it did, but a solution based on what GUCs the build-farm happens to set doesn't seem like it's justified for the narrowness of the case we're testing here.Whether or not we allow this case to work without arewrite is in some sense arbitrary. There's no real reason it can't be done; rather, we're just exercising restraint to minimize the risk of future bugs. So I don't want to go to great lengths to test it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: