Re: PostGres Doubt - Mailing list pgsql-hackers

> -----Original Message-----
> From: Michael Meskes [mailto:meskes@postgresql.org]
> Sent: Thursday, June 13, 2002 3:06 AM
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] PostGres Doubt
>
>
> On Wed, Jun 12, 2002 at 11:46:47AM -0700, Dann Corbit wrote:
> > I should apologize for being rather harsh about embedded SQL for
> > PostgreSQL.
>
> Also about being harsh about the people? Okay, apologies accepted.
>
> > I actually spent a great deal of effort trying to write
> some tools using
> > the PostgreSQL version of ECPG, and found fatal flaws that
> threw away a
>
> Which ones? If it's just SQLDA, this is pretty well
> documented. Yes, the
> feature is missing, but we all have only limited time for postgresql
> work.

Allow me to apologize again.  I have clearly gotten off on the wrong
foot here.  In 6 months of 8 hour days, I would not be able to create a
tool with the functionality that you have provided.  It is an amazing
piece of work.  The point I was (badly) trying to make is that because
of some of the limitations of PostgreSQL's ECPG it is impossible for me
to use it.  Now, *all* of the applications I work with are
multithreading so my situation may be very different from that of some
others.
> > A reentrant version of ECPG that uses SQLCA and SQLDA like
> Oracle or Rdb
> > or DB/2 or any of the professional database systems.
>
> The last time I used Oracle it used SQLCA in a very similar
> way as ECPG
> does.

You are right about Oracle.  They use global variables in embedded SQL.
(I did not write our company's Oracle driver.)  It remains true for all
the others that they are multithread capable.  It is far better to not
make the SQLCA and SQLDA structures global.  Since Oracle's model and
that of PostgreSQL are very similar (for example in concurrency), it is
unsurprising that it might be chosen as a model for implementation of
embedded SQL.

Let me:
1.  Wipe the egg off my face
2.  Personally apologize to the entire list and especially to the
originators of PostgreSQL's ecpg
3.  Restate my opinion in a better way:

"PostgreSQL's implementation of embedded SQL is very good.  The grammar
is complete, it is open source, and highly functional.  The licensing is
a dream -- useful for any sort of endeavor.  There are a couple minor
issues that would enhance the functionality of ecpg even more.  If the
SQLCA were made a local variable to the query, it would be possible to
have multiple threads of execution.  If PostgreSQL's ecpg were enhanced
to have SQLDA structures as specified by "X/Open DR" it would enhance
the functionality even further.  If such features were added, it would
be possible to use ecpg in multithreaded applications, in web servers,
in ODBC drivers.  In fact, it would become the method of choice for
almost any sort of application."

I am reminded of Benjamin Franklin, who once said:
"You can catch more flies with a teaspoon of sugar than with a gallon of
vinegar."