Re: Second thoughts on CheckIndexCompatible() vs. operator families

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Second thoughts on CheckIndexCompatible() vs. operator families
Date: 2012-01-28 23:05:41
Message-ID: 5181.1327791941@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Thu, Jan 26, 2012 at 08:23:34AM -0500, Robert Haas wrote:
>> I'm just going to remove the test. This is not very future-proof and

> [ objections ]

FWIW, I concur with Robert's choice here. This test method is ugly and
fragile, and I'm not even thinking about the question of whether an
installation might have GUC settings that affect it. My objection is
that you're assuming that nowhere else, anywhere in the large amount of
code executed by the queries under test, will anyone ever wish to insert
another elog(DEBUG) message.

> I used the same strategy in another ALTER TABLE patch this CF:
> http://archives.postgresql.org/message-id/20120126033956.GC15670@tornado.leadboat.com

That's going to need to be removed before commit too, then.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-01-28 23:20:56 Re: unfriendly error when accessing NEW in statement-level trigger
Previous Message Jan Urbański 2012-01-28 23:00:38 unfriendly error when accessing NEW in statement-level trigger