Re: Second thoughts on CheckIndexCompatible() vs. operator families - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Second thoughts on CheckIndexCompatible() vs. operator families
Date
Msg-id CA+Tgmob-mg7WngDk2duvYuGy7Wkwd8mjLMSicwL8ebGSuBfecA@mail.gmail.com
Whole thread Raw
In response to Re: Second thoughts on CheckIndexCompatible() vs. operator families  (Noah Misch <noah@leadboat.com>)
Responses Re: Second thoughts on CheckIndexCompatible() vs. operator families  (Noah Misch <noah@leadboat.com>)
List 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 by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [v9.2] sepgsql's DROP Permission checks
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: psql NUL record and field separator