Version française
Home     About     Download     Resources     Contact us    
Browse thread
Type-safe interface to Postgres's SQL
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Richard Jones <rich@a...>
Subject: Type-safe interface to Postgres's SQL
Last year I wrote about my idea for a type safe interface to
PostgreSQL here:
(See also Alex Baretta's criticism in the same thread).

Well, I actually implemented this after a lot of pain:

A typical type-safe program is attached to the end of this message.

There are a number of unanticipated problems with the implementation:

(1) Error reporting is a bit confusing.  Actually I think this is an
issue for any non-trivial camlp4 extension to the language.  You get a
message which doesn't relate to code which you actually wrote, but
instead to the code expanded from the macro.

(2) PostgreSQL doesn't track NULL types properly so we have to do a
bit of non-trivial guesswork to try to find out if a database field
could contain a NULL or not (and therefore whether to map its type to
'a or 'a option).  For parameters this isn't possible at all, so all
parameter variables must have an option type.  For result fields, it
is usually possible to tell if the result corresponds to a known
column in the database, which is the case in ninety percent of

(3) You need to have access to the real database at compile time, as
discussed in my original message.  This is because we prepare the
statements on the database engine and then ask the database engine to
tell us the types of the parameters / results, and use this to
generate code which makes the magic of type inference work on the
OCaml side.  Of course we don't _execute_ the statements at compile
time - which would have horrible side-effects.  Except that in some
cases we need to execute the statement at compile time.  The
particular case is when the statement is "CREATE TEMPORARY TABLE",
because subsequent code needs to actually have the temporary table
there in order to check later statements which access this table.  So
I've added a special case to cope with "CREATE TEMPORARY TABLE", which
might be regarded as something of a hack.  You would probably never
need to use this hack in Real Code, but the nature of test scripts
like the one attached is that they do create temporary tables.

BTW, I don't think any of this is necessarily "better" or "worse" than
the existing PG interfaces out there -- just different.


(* Example program using typesafe calls to PostgreSQL.
 * $Id:,v 1.3 2006/01/31 13:22:36 rich Exp $

open Printf

let () =
  let dbh = PGOCaml.connect () in

  PGSQL_EXECUTE_ON_COMPILE(dbh) "create temporary table employees (
     id serial not null primary key,
     name text not null,
     salary int4 not null,
     email text

  let insert name salary =
    PGSQL(dbh) "insert into employees (name, salary)
                values ($name, $salary)"
  insert (Some "Ann") (Some 10_000_l);
  insert (Some "Bob") (Some 45_000_l);
  insert (Some "Jim") (Some 20_000_l);
  insert (Some "Mary") (Some 30_000_l);

  let rows = PGSQL(dbh) "select id, name, salary, email from employees" in
  List.iter (
    fun (id, name, salary, email) ->
      let email = match email with Some email -> email | None -> "-" in
      printf "%ld %S %ld %S\n" id name salary email
  ) rows;

  PGOCaml.close dbh

Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology -
Team Notepad - intranets and extranets for business -