Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] PostgreSQL-OCaml 1.0.1
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-01-30 (12:43)
From: Benjamin Geer <ben@s...>
Subject: Re: [Caml-list] PostgreSQL-OCaml 1.0.1
Richard Jones wrote:
> It throws Sql_error when it can determine an error.  I'm not very
> familiar with JDBC, except that I know a lot of people don't like it.
> mod_caml's Dbi is much more closely related to Perl DBI, as you might
> have guessed.

If the exception string just contains whatever error message the 
database produced, the application will have to parse the string to find 
out what went wrong.  And since different databases produce different 
error messages, this removes some of the benefit of having an DBI layer 
in the first place.  So it would be nice to have something like this:

type sql_error_type = Invalid_sql | Lost_connection | Deadlock | Other ;;

exception SQL_error of sql_error_type * string ;;

It might be a good idea to have a look at the error codes returned by 
Oracle, DB2 and SQL Server, and try to come up with some reasonable 
vendor-neutral codes for the DBI layer.

>>Can it handle 
>>BLOBs and CLOBs?
> Since we use PostgreSQL for everything at Merjis, we use the 'text'
> and 'byte' types which are much more useful and flexible than BLOBs.
> So there's no specific support, although it wouldn't be too hard to
> add it.  I've no idea how Perl DBI handles BLOBs either,

A friend of mine who has been working with Perl DBI and Microsoft SQL 
Server says it doesn't seem to handle them at all.

> since all the
> databases I've ever used with it have had proper unlimited length text
> types, so there's no need for them.

PostgreSQL and MySQL are great databases, but all the banks we work with 
are very attached to either Oracle, DB2 or SQL Server, so it's essential 
for us to support those databases.  (Asking a bank to switch to a 
different database vendor is like asking the Pope to convert to another 


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: