On Fri, May 23, 2014 at 8:15 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers