# enabling postgresql by default - Thread: https://externals.io/message/2684 - Original archive: https://news-web.php.net/php.internals/2684 - Started by Chris on 2003-06-24T06:32:58+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #2684 — Chris — 2003-06-24T06:32:58+00:00 URL: https://externals.io/message/2684#2684 All, Since there's been a lot of talk about disabling mysql by default (and having another option available), the PostgreSQL people are pretty excited about this and are keen to see what can be done about getting postgres enabled by default instead. What do people think about this? How can we "influence" the decision? Cheers, Chris. --- ## #2685 — James Cox — 2003-06-24T06:50:54+00:00 URL: https://externals.io/message/2684#2685 · In reply to: #2684 > > Since there's been a lot of talk about disabling mysql by > default (and > having another option available), the PostgreSQL people are > pretty excited > about this and are keen to see what can be done about getting > postgres > enabled by default instead. > I certainly don't speak for all. But I would like to throw my hat in on this -- why not stop enabling stuff by default ... We really don't need to. Many developers complain that our users are stupid, or whatever other discrediting statement that seems to be in fashion. By educating them (ie, helping them along a little, requiring that they get to know ./configure options) the chances are that they will not appear to be quite so stupid anymore. Ok. Getting to a point: bundling things is PHP telling users what tools they should use. Yes, there is --without- but it doesn't help a newer user, and it certainly doesn't show that we are adhering to some sort of standard about enabling by default, and bundling comes into it too. Therefore, I propose that we: -- limit bundled code to _only_ code that is either hard to find and install or we have chosen to fork (eg, gd), or is core code which we can not live without. (i.e. the build fails -- eg, pcre). -- limit enabled-by-default extensions to only those which have a significant reasoning behind it (ie, like pcre, which is core code and would cause breakages without it), AND comes along with 10 positive votes for enabling. I admit that perhaps these guidelines are not encompassing, and I can already see loopholes. I encourage other members of this list to propose changes and enhancements, but one thing we must prevent is this notion of bundling/enabling code based on the whim and fancy of one or a few developers. PHP doesn't need to become known as PHP with CPANesque bloat attached on. I look forward to the day where we can distribute a version of php with just the engine, the build system, main/ and ext/standard - the real core of PHP. --- ## #2686 — Derick Rethans — 2003-06-24T06:52:00+00:00 URL: https://externals.io/message/2684#2686 · In reply to: #2684 > Since there's been a lot of talk about disabling mysql by default (and > having another option available), the PostgreSQL people are pretty excited > about this and are keen to see what can be done about getting postgres > enabled by default instead. > > What do people think about this? We're not bundling the library with PHP, so we can not enable it by default. Derick -- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ --- ## #2690 — Zeev Suraski — 2003-06-24T11:03:41+00:00 URL: https://externals.io/message/2684#2690 · In reply to: #2684 I suggest we don't open this discussion again. The archives are full of past discussions. We'll continue with the status-quo barring major, tiring discussions to change it. Zeev At 09:50 24/06/2003, James Cox wrote: > > […] > >I certainly don't speak for all. But I would like to throw my hat in on >this -- why not stop enabling stuff by default ... We really don't need >to. Many developers complain that our users are stupid, or whatever >other discrediting statement that seems to be in fashion. By educating >them (ie, helping them along a little, requiring that they get to know >./configure options) the chances are that they will not appear to be >quite so stupid anymore. > >Ok. Getting to a point: bundling things is PHP telling users what tools >they should use. Yes, there is --without- but it doesn't help a >newer user, and it certainly doesn't show that we are adhering to some >sort of standard about enabling by default, and bundling comes into it >too. > >Therefore, I propose that we: > > -- limit bundled code to _only_ code that is either hard to find and >install or we have chosen to fork (eg, gd), or is core code which we can >not live without. (i.e. the build fails -- eg, pcre). > > -- limit enabled-by-default extensions to only those which have a >significant reasoning behind it (ie, like pcre, which is core code and >would cause breakages without it), AND comes along with 10 positive >votes for enabling. > >I admit that perhaps these guidelines are not encompassing, and I can >already see loopholes. I encourage other members of this list to propose >changes and enhancements, but one thing we must prevent is this notion >of bundling/enabling code based on the whim and fancy of one or a few >developers. PHP doesn't need to become known as PHP with CPANesque bloat >attached on. > >I look forward to the day where we can distribute a version of php with >just the engine, the build system, main/ and ext/standard - the real >core of PHP.