Re: Upcoming re-releases

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Devrim GUNDUZ <devrim(at)commandprompt(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Upcoming re-releases
Date: 2006-02-10 09:48:19
Message-ID: e51f66da0602100148w6e1deb39ke85ee7a0599ce536@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/9/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > Maybe this should be a configure flag, just like the port number is.
>
> It is ... that isn't the issue, the problem is exactly that Debian
> chooses to exercise the option to make their installations different
> from everyone else's.

It is exatly distributor's job to give consistent system. I would
not like to use a distro that just does './configure;make;make install'
without any overview.

Especially considering that upstream defaults are bad.

OTOH as upstream job is _not_ to care about consistent system
- as it is not possible - then for upstream the backwards compatibility
is the most important thing. It is likely that PostgreSQL upstream can
move the default only when most distros have already changed to sane
setting.

Oh, and I personally like that self-compiled PostgreSQL defaults to
other locations than system one. Lessens danger of using experimental
stuff on useful data.

--
marko

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ITAGAKI Takahiro 2006-02-10 10:12:48 Re: TODO-Item: B-tree fillfactor control
Previous Message Michael Glaesemann 2006-02-10 08:35:28 Re: FW: PGBuildfarm member snake Branch HEAD Status changed from OK to ContribCheck failure