RE: [Catacomb] [Ann] Catacomb ODBC
Jim Whitehead wrote:
> Ricardo Rocha writes:
> > However, I tend to think ODBC makes per-RDBMS modules redundant. My
> > question
> > is: why should we incur the additional effort of writing
> > RDBMS-specific ports when ODBC gives us an efficient,
> > one-size-fits-all solution?
> I'm under the impression that ODBC is not quite
> one-size-fits-all. That said, I'll freely admit to not having
> deep expertise in ODBC.
ODBC allows writing code that is highly portable across a wide spectrum of
RDBMS's. For Catacomb, in particular, I dare say there's *nothing* in the
original MySQL version that cannot be fully and equivalently expressed in
ODBC. The same applies to other databases (Oracle and Postgres having been
In all fairness, ODBC portability is not without its limitations. In the
Catacomb case, for instance, we had to define a SUBSTRING function for
Oracle and a CONCAT function for Postgres. In this case, admittedly, the SQL
used is portable only as long as the target RDBMS allows one to create new
functions or as long as one limits SQL function usage to a minimal subset.
Thank goodness this can be done with most mainstream databases...
> > I also don't understand how ODBC could be at odds with stored
> > procedures. SP's are fully supported by ODBC. What can be
> achieved via
> > native interfaces that cannot be achieved via ODBC?
> I was not aware that ODBC supports stored procedures.
Yes it does, of course.
Where are stored procedures used in Catacomb? I ask this question because
the existing codebase does not use them at all. Probably some installation
using an unpublished extension to Catacomb?