Re: libpq and prepared statements progress for 8.0 - Mailing list pgsql-hackers

> -----Original Message-----
> From: gsstark@mit.edu [mailto:gsstark@mit.edu]
> Sent: Wednesday, September 15, 2004 11:34 AM
> To: Tom Lane
> Cc: Dann Corbit; Greg Stark; Merlin Moncure;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] libpq and prepared statements progress for 8.0
>
>
>
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> > "Dann Corbit" <DCorbit@connx.com> writes:
> > > What about using ECPG as an interface for drivers?
> >
> > What for?  It's not a substitute for libpq --- it sits on top of
> > libpq, or did last I checked anyway.  And it's designed around a
> > preprocessor that seems fairly useless for a driver.
>
> As it happens DBD::Oracle does use Oracle's precompiler. But
> it's more of a hindrance than a help. It basically has to
> define and implement its own API which is compiled with
> Pro*C. Then the rest of the codebase can ignore the
> precompiler and use that interface.
>
> Precompilers are really old school. There's not much point to
> using them except in legacy applications that need them. They
> offer no advantage over a programmatic API, and lots of
> disadvantages. You have to learn a new language, you're one
> step further removed from the resulting code, and heaven help
> you if your compiler version doesn't match what the
> precompiler was tested with. Nevermind actually trying to use
> it from another language entirely.

The nice thing about using the SQL precompiler was that it was very
simple.

A total of 15 interfaces needed to be defined:
PROCEDURE PREPARE_STMT
PROCEDURE DESCRIBE_SELECT
PROCEDURE DESCRIBE_PARM
PROCEDURE EXECUTE_STMT
PROCEDURE EXECUTE_IMMEDIATE
PROCEDURE DECLARE_CURSOR
PROCEDURE DECLARE_LIST_CURSOR
PROCEDURE DECLARE_CURSOR_READ_ONLY
PROCEDURE DECLARE_LIST_CURSOR_READ_ONLY
PROCEDURE DECLARE_CURSOR_INSERT_ONLY
PROCEDURE DECLARE_LIST_CURSOR_INSERT_ONLY
PROCEDURE OPEN_CURSOR
PROCEDURE FETCH_ROW
PROCEDURE CLOSE_CURSOR
PROCEDURE RELEASE_STMT

And each one was only a few lines (the entire SQLMOD file, including
comments is 5695 bytes long).
A C++ wrapper was written around these statements, and the C++ wrapper
is what is used from the applications that exercise the underlying
SQLMOD interface.

It was also considerably FASTER than using the C API directly.  This is
probably due to Rdb being ANCIENT technology, and quite possibly the C
API is written over top of SQLMOD rather than the other way around.

At any rate, it is very simple to write a generic interface using a
precompiler.

However, if the PostgreSQL precompiler is not reentrant, it is a waste
of time.  My thought was that ECPG might deliver the missing
functionality needed by the Perl interface.  Since ECPG sits on top of
libpq, and libpq seems to lack some needed feature, it seems highly
unlikely that it can provide what is missing.