Why would you push Perl into a niche like that? Perl can handle many many database systems. Instead of creating this limitation, I'd rather see people think of Perl as "ah, yes, will work with my database".

And of course you could also write a book on "Web Development with Perl and SQLite". Much more fun ;-)

Because PHP/MySQL has been done to death by the publishing world whereas there's relatively little coverage of Postgres. Even less coverage of Perl web development. I say now is the time because as Postgres becomes more popular we may soon see a boat load of PHP/Postgres books as publishers look for unchartered territory. It's not a question of limiting Perl but getting Perl a bit more exposure in the web devlopment book market.

Just because PHP/MySQL has a lot of books out in the wild, doesn't mean that you must spit out a lot of books to counter it. If people want to use PHP/MySQL, so be it. If people want Perl/MySQL, or Perl/PostgreSQL, fine too. I couldn't care less. All I care about is for the PHP community to drop the annoying php prefix in every project (except for phpMyAss) Then again, it makes it easier to ignore certain projects ;-)

I don't think focussing on a niche is going to gain a lot of 'mortal souls' though, quite the opposite. You hope that people -who have never seen anything but PHP and MySQL- take the huge step in changing not only the database type, but also the programming language. I doubt if it's ever going to happen. Especially because most PHP 'programmers' seem quite happy with what they have.

Changing two things at once is probably raising a huge threshold. Imagine the Python community telling you to drop Perl and PostgreSQL and join them with Python and, let's say, Oracle (and yeah, I know very, very little about both). I'd tell them: "Why? I'm perfectly happy with Perl and PostgreSQL/MySQL/SQLite!". And I predict the PHP people out there will react the same.

Instead of creating your niche, why not write books about "Web Development with Perl and (Class::)DBI" and let people see that you can use MySQL and PostgreSQL. In there you could -of course- point out why PostgreSQL would be better according to you. That way, you don't raise the suggestion that Perl is only suitable for PostgreSQL and thus not for person X, who only knows MySQL.

--
b10m

All code is usually tested, but rarely trusted.

Terrible idea.

I love Perl/DBI because I can do everything I need to do with several DBMSs,ing the same interface, and I don't like the idea of limiting Perl's acceptance by linking it to a single DBMS, no matter how good it could be, and I have my doubts abut the specific one you are proposing.

Sure, the PHP/MySQL curse is reason for grief, but why do you want to counter a wrong with a even bigger wrong?

I personally use Perl with Oracle, Informix, MySQL, PostgreSQL, SQLite. And, guess what? Most of the problems I had with the DBI came from DBD::PostgreSQL, which seems to have a driver that is not fully DBD compliant (See this node for just an example). And surely you aren't proposing the usage of Pg instead of DBD::Pg, or are you?

Please, leave Perl as it is: a magnificent agnostic tool.

rnahi / other monks, I'm a dbi newbie, thinking of using postgres for a db app (while I will also be learning dbi), so whenever I hear things like "pg not fully dbi compliant" I start worrying.

But the link you posted Re: Speeding up the DBI seems quite inconclusive to me. While I'm mulling that node over, trying to predict for myself how much aggravation I may or may not be incurring for myself by using pg, I would appreciate it if you or others would be more specific about where pg falls down, as definitely as possible (no FUD please!).

This question should be better asked in SoPW, instead of here.

Anyway, use Super Search, and you'll find thinks like

• Why is DBD::Pg slower than DBD::mysql?
• DBI / DBD::PgPP vs. Pg

Hmm. I wouldn't get overly concerned about the finer points of using cursors in SQL if you are just starting out. They are very useful for a small subset of problems, although you can almost always get around the problems in other ways. And if you simply must use cursors then DBI can call a stored procedure in the database which then uses them ( although this depends on what you think of stored procedures...).

In summary if you are just starting out then worrying about cursors is like worrying about wether a car is front or back heavy when skidding round a race track when you are just starting your driving lessons :)

If you want ease of installation go with SQLite. If you don't mind a little more hassle setting things up go with Postgres - it has nicer error messages. Can't comment on MySQL.

-- Me, me, me: http://prlmnks.org/rss-feeds.html, http://scrpbk.com/~evdb, http://ecclestoad.co.uk.

Actually I think the point made in the referenced node was more that DBI doesn't give you the facilities to get the best performance out of PostgresSQL in all circumstances, the incompatibility, if any, is the reverse if you want to put it in those terms. For myself whenever this has been a problem I have just targetted the pgsql C API in XS code - though this might not be an option for a beginner.

/J\

jayrom

It is always difficult to compare two things, unless one is better than the other in all senses. However MySQL does win two important aspects:

• Speed. PostgreSQL targets a full set of features, when MySQL aims performance. Performance is extreamly important for database applications. It is easier for you to work around the features, the worst just go the long way, do more coding yourself. There is almost no way to get around performance. You can do things to speed up the application, but evetually it is determined by the database.
• Security. MySQL grants much finer access control of database components.

See yesterdays slashdot article about Comparing MySQL and PostgreSQL

Walking the road to enlightenment... I found a penguin and a camel on the way.....
Fancy a yourname@perl.me.uk? Just ask!!!

Speed: how many concurrent connections are we talking about here? Given equal hardware, PG supports a greater number of concurrent connections without bogging down; and with the 8.0 release, speed is on-par with MySQL in most areas. Look for speed improvements in 8.1.

Security:
"By default, PostgreSQL is probably the most security-aware database available ..."
Database Hacker's Handbook
Lithcfield et. al.
Wiley
Wiley

good points. The extra features have to be very very tempting to be more important than speed and security.

PostgreSQL targets a full set of features, when MySQL aims performance.

But from what I have read, it aims and misses, at least when you have an application that requires lots of updates, like a big e-commerce site.

Without PostgreSQL's MVCC "concurrent update" feature, MySQL programs are required to lock the entire table to perform updates. This gets to be the bottleneck for such applications.

So, while MySQL may be "speedier" on simple tests or mostly-readonly accesses, PostgreSQL is faster (and some say more robust) for real transactions.

MySQL is structured access to files. PostgreSQL is a real transactional database. Your needs determine which is more appropriate. But please stop trotting out "speed" as a complete determiner.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Well, I only started working on sited with a db recently. I jumped into mysql first, because at the beginning you are unsure of what you're getting into, and a large user base, loads of web info, and so on, has a strong attraction from that position. That is perfectly logical.

Now, after a few months, I see the possibilities of Posgres - but will I be limited enough by mySql to change at some point? Maybe, if I go for a big teardown/rebuild, which may happen. But it won't be for a while.

For many in my situation, it would be never.

A twist on a phrase here - build a brighter LAMP.

Linux, Apache, Mod_perl, PostgreSQL