Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] interesting PHP/MySQL thread

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Sterling Hughes <sterling(at)bumblebury(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Josh Berkus <josh(at)agliodbs(dot)com>, Joe Conway <mail(at)joeconway(dot)com>,"Advocacy (PostgreSQL)" <pgsql-advocacy(at)postgresql(dot)org>,PostgreSQL-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: [GENERAL] interesting PHP/MySQL thread
Date: 2003-06-23 16:47:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacypgsql-general
On 23 Jun 2003, Sterling Hughes wrote:

> > > 
> > > > SQlite is even less competition from our point of view than MySQL is
> > > > ... if the PHP guys think their users will be satisfied with SQlite,
> > > > let them try it for awhile.
> > > > 
> > > 
> > > This is actually my point in choosing SQLite.  I've used both MySQL and
> > > PostgreSQL extensively, and I like both systems alot (please, I don't
> > > mean to start a war on which database is better here.)  SQLite is not
> > > really a competitor to either of these solutions.  MySQL and PostgreSQL
> > > are both database servers, SQLite isn't.  Just because they all speak a
> > > SQL dialect, certainly doesn't mean they are the same thing.
> > > 
> > > But one of the most common things that people want to do with PHP is
> > > save data.  Many sites don't require a relational database system.  For
> > > example, implementing a weblog system with a RDBM system is overkill. 
> > > SQLite fills the nice nicely.  It provides a coherent system for doing
> > > simple stuff.  No need to worry about locking, data formats, etc.  And
> > > most importantly, no database server is required, so you can write an
> > > app for sqlite, and have it always available, on every shared host.
> > 
> > What about concurrency issues?  It may well be that a system built to log 
> > with a non-concurrent database works fine until it hits a certain load 
> > point, then data starts to get corrupted due to parallel access issues.
> That's what you have locking for.  That's actually what you have sqlite
> for.  One of the "common" problems as you mention it are that people
> write file logic themselves.  Its also very fast so long as your not in
> a write heavy environment (in which case performance is terrible, but
> not as bad as it would be with custom PHP solutions).  
> SQLite is in my opinion a great flat file abstraction interface.  It
> handles all the issues surrounding file access - concurrency, paging,
> buffering, etc.   And it provides a familair, abstracted interface to
> accessing data in these files.
> Would I use it as an RDBM? Hell no.
> Would I use it to build a weblog system? Hell yes.
> Remember, PHP is widely used on shared hosting providers.  Many of whom
> don't wish to provide an RDBM, and tangle with permissions, performance,
> and user support requirements.  SQLite is a godsend for those people who
> don't have access to any other solutions.
> > 
> > It's quite common for me to see people saying "we don't need something as 
> > complex as postgresql" then 4 months later, when their log files or 
> > whatever they're doing get corrupted, they want a quick fix.  The quick 
> > fix is usually to switch to a database oriented system.
> > 
> > I would at least hope that PHP would pickup the postgresql headers if it 
> > sees them and include postgresql support automagically.
> > 
> > And I agree with the point made in the php dev mailing list that getting 
> > an exception is a Bad Thing.  It goes against the whole open source 
> > concept.  Plus, I don't think you can actually author a "GPL exception" so 
> > it would have to be an exception to the commercial license, i.e. PHP use 
> > automatically gives on a free commercial licensed version of MySQL.  If 
> > it's an exception based on the commercial license, it can likely be 
> > revoked in the future.
> > 
> > MySQL AB are playing the PHP community.  PHP is my primary development 
> > environment, and I'd hate to see its well get poisoned by this behaviour 
> > of MySQL AB.
> Uhmm.  MySQL AB are not "playing" the PHP community. I happen to know
> the folks doing the licensing quite well, and while I don't particularly
> like how its been handled, I'm certain there was/is no intent to play
> PHP. 

The primary reason for changing the 4.x connect lib to GPL was to 
encourage people to buy commercial software licenses.

In my opinion, this is playing the GPL community.  PHP happens to be part 
of the community they are playing.

What other reason can there be for switching their licensing of their 
connect libs while also making sure that 4.x won't talk to an app using 
the LGPL'd 3.x connection library?

> In any event, MySQL is debundled.  While I'm not thoroughly convinced
> that PostgreSQL needs to bundled/automagically enabled,  I probably
> wouldn't be against automagical detection. (*)

I agree with this.  I think bundling a connect lib directly in raises a 
lot of issues with forward / backward compatibility, and would much rather 
the connect lib installed with the product be detected and used at build 
time.  I would say that if a box has any of the standard free connect libs 
(LGPL or less restrictive) on it, then it's probably a good idea to 
automagically detect and include support for them, not just pgsql or 
SQLite, but interbase, and all the others.  It's just easier for Joe 
Beginner if he doesn't have to enter a --with-dbnamehere switch everytime 
he builds to get connectivity.

> (*) Note, I was personally against bundling libmysql as well.  I speak
> for myself, as one voice in the PHP community.  You're best off making
> this case on internals(at)lists(dot)php(dot)net if you want PostgreSQL to be
> further supported.

Thanks for the recommendation.  I'll take a look at that list when I have 
a moment.

As an aside, I'd highly recommend auto-including gdbm ability when 
building if it's detected.  I find it far more intuitive to access a DBM 
style database from there than using a SQL interface.  Plus it's a pretty 
small lib, and including it means you have a supported package that is 
known to work well for people who want simple database type access.

In response to


pgsql-advocacy by date

Next:From: scott.marloweDate: 2003-06-23 16:55:09
Subject: Re: [GENERAL] interesting PHP/MySQL thread
Previous:From: Bruce MomjianDate: 2003-06-23 16:41:55
Subject: Re: [GENERAL] interesting PHP/MySQL thread

pgsql-general by date

Next:From: Jason UnderdownDate: 2003-06-23 16:51:22
Subject: Re: Unable to create or drop plpgsql
Previous:From: Bruce MomjianDate: 2003-06-23 16:41:55
Subject: Re: [GENERAL] interesting PHP/MySQL thread

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group