From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Dann Corbit" <DCorbit(at)connx(dot)com>, "Greg Stark" <gsstark(at)mit(dot)edu>, "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: libpq and prepared statements progress for 8.0 |
Date: | 2004-09-15 18:33:34 |
Message-ID: | 873c1jtm9t.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> "Dann Corbit" <DCorbit(at)connx(dot)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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-09-15 18:47:45 | Re: libpq and prepared statements progress for 8.0 |
Previous Message | Tom Lane | 2004-09-15 18:11:55 | Re: libpq and prepared statements progress for 8.0 |