|
»
« Return to Thread: "ocaml_beginners"::[] De-unifying variant types
Re: "ocaml_beginners"::[] De-unifying variant types
by Richard Jones-4
::
Rate this Message:
On Wed, Jul 25, 2007 at 09:49:05PM -0000, cultural_sublimation wrote:
> > The idea of being "locked in" to free software. Well, I guess
> > PG'OCaml does require PostgreSQL, but that's only because it is the
> > only database which has the necessary 'DESCRIBE' statement (which,
> > given a statement, parses it and tells you what types it takes and
> > returns). If other databases have it, then you could add support for
> > them.
>
> Hi,
>
> Well, if it means that you can't easily plug-out Postgresql and
> plug-in another DB, it is a sort of lock-in, even if it is much
> softer than the lock-in you get with proprietary products!
Once you start to strongly type your database statements you'll find
that most code requires porting, even between different versions of
the same DBMS, nevermind between entirely different DBMSes.
For example we discovered that Postgres like to play with the length
of various integer/serial/... types between releases. For this reason
COCANWIKI needs some source code modifications if you use it with PG
8.x versus PG 7.4 which is what I'm using. The changes are trivial
and mechanical -- statements return int64's instead of int32's -- but
they are there nevertheless.
> But anyway, does the type verification of PG'OCaml go all the
> way into ensuring that SQL injection attacks are not possible?
Of course. I'd regard this as a basic requirement of _any_ database
binding, whether or not it was type safe.
> And does it provide also for such things as prepared statements,
> and the entire range of SQL statements? If so, I am willing
> to take another look into it...
Yes & yes. Prepared statements are mandatory and invisible to the
programmer if you are using the high level (ie. normal) PG'OCaml
interface. You can use the low level PG'OCaml interface which is not
type safe and allows you to separately prepare & execute statements if
you wish. Any (well, almost any) Postgres statement can be used
directly with PG'OCaml. There are a few exceptions but they are
pretty esoteric, non-portable, PG-specific features.
Rich.
--
Richard Jones
Red Hat
> > The idea of being "locked in" to free software. Well, I guess
> > PG'OCaml does require PostgreSQL, but that's only because it is the
> > only database which has the necessary 'DESCRIBE' statement (which,
> > given a statement, parses it and tells you what types it takes and
> > returns). If other databases have it, then you could add support for
> > them.
>
> Hi,
>
> Well, if it means that you can't easily plug-out Postgresql and
> plug-in another DB, it is a sort of lock-in, even if it is much
> softer than the lock-in you get with proprietary products!
Once you start to strongly type your database statements you'll find
that most code requires porting, even between different versions of
the same DBMS, nevermind between entirely different DBMSes.
For example we discovered that Postgres like to play with the length
of various integer/serial/... types between releases. For this reason
COCANWIKI needs some source code modifications if you use it with PG
8.x versus PG 7.4 which is what I'm using. The changes are trivial
and mechanical -- statements return int64's instead of int32's -- but
they are there nevertheless.
> But anyway, does the type verification of PG'OCaml go all the
> way into ensuring that SQL injection attacks are not possible?
Of course. I'd regard this as a basic requirement of _any_ database
binding, whether or not it was type safe.
> And does it provide also for such things as prepared statements,
> and the entire range of SQL statements? If so, I am willing
> to take another look into it...
Yes & yes. Prepared statements are mandatory and invisible to the
programmer if you are using the high level (ie. normal) PG'OCaml
interface. You can use the low level PG'OCaml interface which is not
type safe and allows you to separately prepare & execute statements if
you wish. Any (well, almost any) Postgres statement can be used
directly with PG'OCaml. There are a few exceptions but they are
pretty esoteric, non-portable, PG-specific features.
Rich.
--
Richard Jones
Red Hat
« Return to Thread: "ocaml_beginners"::[] De-unifying variant types
| Free embeddable forum powered by Nabble | Forum Help |
