Re: PGXLOG variable worthwhile? - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: PGXLOG variable worthwhile?
Date
Msg-id 3D861B9F.3874F864@Yahoo.com
Whole thread Raw
In response to Re: PGXLOG variable worthwhile?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Justin Clift wrote:
> 
> Jan Wieck wrote:
> <snip>
> >
> > I just don't see why that all could become an issue. Someone
> > running big stuff on NT4 today is not running a native PostgreSQL
> > port on it. Why would someone want to do a new, big, PG
> > installation on an old, unsupported NT4 server today?
> 
> Corporate Standards.  Even if everyone *knows* that NT4 isn't the latest
> and greatest, many large companies still use NT4.  Purely because so
> much stuff they use works with it that they haven't been able to
> generate sufficient business cases to migrate their base server OS to
> Win2K (or XP).

The word construct "corporate standard" is the most expensive and
dangerous form of ignorance I've seen in the business. One of the
best examples I've seen actually fit's very well. An SAP customer
converting from R/2 to R/3 a couple years ago. They ran all their
non-mainframe business on HP3000 MPE/IX systems. We strongly
recommended using HP/UX for the SAP installation instead, but
they followed their "corporate ignorance" anyway. Two weeks
before going life SAP informed all their MPE customers that
support for that operating system will be abandoned and strongly
recommended converting to HP/UX soon because within a few months
not even hotfixes will be provided any more. Outch!

If corporate standard means similar letter heads, similar
appearance of public offices or advertising, absolutely a good
thing and I'm all for it. But if it causes to get stuck with old
technology, then the corporate standard itself is the problem
that needs to be fixed first.

But ... let's put it into the damned config file and move on.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being
right. #
# Let's break this rule - forgive
me.                                  #
#==================================================
JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal for resolving casting issues
Next
From: Justin Clift
Date:
Subject: Re: PGXLOG variable worthwhile?