Re: Porting reports (cont'd)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, ohp(at)pyrenet(dot)fr, Postgres Hackers List <hackers(at)postgresql(dot)org>
Subject: Re: Porting reports (cont'd)
Date: 2000-05-05 22:50:39
Message-ID: 8396.957567039@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> Compiler bugs are a PITA. But Postgres can't have inline code to
>> handle all cases, esp. cases like this. "if (var op const)" is imho
>> the usual style for comparisons, and obfuscating that for a single
>> buggy platform isn't a Good Thing.

> The bigger problem is that just fixes the comparison done by the
> regression tests. Who knows how many other comparisons are broken. I
> say leave it broken and don't trust it. If we fix just the
> regression-shown fault, we give users a false sense of security.

Excellent point...

What we've usually done in the past, when faced with compiler problems,
is to cut down the optimization setting selected by the platform's
template file. If that helps for Unixware then it'd make sense to do
it, IMHO.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-05-05 22:51:48 Re: Porting reports (cont'd)
Previous Message Bruce Momjian 2000-05-05 22:47:44 Re: pg_group_name_index corrupt?