Re: Perl/PostgreSQL niche

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.

Comment on Re: Perl/PostgreSQL niche

Replies are listed 'Best First'.
Re^2: Perl/PostgreSQL niche by tphyahoo (Vicar) on Sep 06, 2005 at 11:34 UTC
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!).	[reply]
Re^3: Perl/PostgreSQL niche by rnahi (Curate) on Sep 06, 2005 at 11:46 UTC
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	[reply]
Re^3: Perl/PostgreSQL niche by EvdB (Deacon) on Sep 06, 2005 at 11:52 UTC
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.	[reply]
Re^3: Perl/PostgreSQL niche by gellyfish (Monsignor) on Sep 06, 2005 at 11:46 UTC
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\	[reply]