Re: [Re] Re: PREPARE and transactions

From: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
To: Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Re] Re: PREPARE and transactions
Date: 2004-07-04 21:41:55
Message-ID: 20040704214155.GZ50626@xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 04, 2004 at 06:39:46PM -0000, Greg Sabino Mullane wrote:

> > There's no actual extra parsing involved, as far as I can see, just
> > pattern matching and the extraction of the variables.
>
> That sounds like "parsing" to me. :)

Depends on your definition, I guess. I would say very limited lexical
analysis, yes, but nothing involving actual structure beyond individual
lexical tokens.

> It's already been done in DBD::Pg. Naming starts at dbdpg_1 and goes to
> dbdpg_2, dbdpg_3, etc. The only requirement we ask of the application
> using it is that you don't prepare statements yourself named "dbdpg_x".
> In most cases, the application does not worry about the naming anyway,
> but simply issues an anonymous prepare request through DBIs paradigm of
> one statement handle bound to a single SQL statement. DBD::Pg also does
> the deallocating itself, and keeps track of the transaction status as well.
> Deallocation is merely a courtesy anyway, as we don't reuse the names.
>
> If there are flaws in the above design, I'd like to know about them,
> as all of this prepare/execute stuff is rather new and undertested.

Can't think of any, as long as you don't try to manage the connection.

Jeroen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-07-04 21:58:50 Re: [HACKERS] Compile failure in plperl
Previous Message Andrew Dunstan 2004-07-04 21:06:06 Re: [HACKERS] Compile failure in plperl