On Fri, May 23, 2014 at 8:15 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> >> I've used it once or twice to avoid having to recompile postgres when I
>> >> wanted things not to be *that* slow (AtEOXactBuffers() I am looking at
>> >> you). But I wouldn't be very sad if it'd go.
>> >>
>> >> Anybody against that?
>> >
>> > I have used it too (for a different reason IIRC), but like you I
>> > wouldn't have a problem if it weren't there.
>>
>> I've used it, too, although not recently.
>
> That means you're for a (differently named) disable macro? Or is it not
> recent enough that you don't care?
I'm leaning toward thinking we should just rip it out. The fact that
3 out of the 4 people commenting on this thread have used it at some
point provides some evidence that it has more than no value - but on
the other hand, there's a cost to keeping it around. The need to
guard some sections of code by both #ifdef USE_ASSERT_CHECKING and if
(assert_enabled) has occasionally been a source of confusion over the
years, and once I had a customer who I was afraid had gotten an
assert-enabled build into production and the only way to distinguish
between an assert-enabled build with assertions shut off via the GUC
and a build that didn't support them in the first place was to try
turning the GUC on and see whether it worked, which led to some
confusion. Now it looks like we need to add another macro to make
this dance even more complicated ... and I'm starting to think it's
just not worth it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
