Re: [PERFORM] Sun performance - Major discovery!

On 14.10.2003, at 19:52, Tom Lane wrote:
> This means that relaxing the check would require (a) finding out which
> of the sub-flags break our code and which don't; (b) finding out how 
> the
> answer to (a) has varied with gcc release; and (c) finding out how we
> can test whether a given sub-flag is set --- are there #defines for 
> each
> of them in gcc 3?

Okay, I can see how that makes this unpractical to implement. Thanks.

The current error message is "do not put -ffast-math in CFLAGS"; does
someone have an idea for a better text that doesn't imply that you
actually /have/ --ffast-math in CFLAGS? It'd be good to acknowledge
that it can be set implicitly, too.

And on the same subject:

On 14.10.2003, at 18:13, Peter Eisentraut wrote:
> That sounds perfectly reasonable to me.  Why should we develop 
> elaborate
> workarounds for compiler flags that are known to create broken code?  I
> also want to point out that I'm getting kind of tired of developing 
> more
> and more workarounds for sloppy Apple engineering.

Peter, you are free to consider your current environment to be the
peak of perfection, but that doesn't mean that the only reason for
differences between your system and others' is the sloppiness of
their engineering.

I'm not aware of any Darwin-specific "workarounds" in the tree
right now; the only thing close to that is the support for Apple's
two-level namespaces feature. And while you can argue the relative
merits of Apple's approach, the reason for its existence isn't
sloppiness and the support for it that was implemented by Tom
most certainly isn't a workaround.

The fact of the matter is that Mac OS X has about ten million active
users, and when one of these people is looking for an RDBMS,  he's
gonna go for one that compiles and works great on his system, rather
worrying if his platform is optimal for running PostgreSQL. Supporting
this platform well is absolutely crucial to the overall adoption of pg,
and even if you consider yourself to be above such pedestrian
concerns, many people who have to make the business case for putting
money into PostgreSQL development most definitely think otherwise.

mk