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
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 |