Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19119
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <003501c5bf6c$1e452bb0$560aa8c0@web03>
To: "Lukas Smith" <lsmith@php.net>
Cc: <internals@lists.php.net>
References: <56.98.24510.D3D82334@pb1.pair.com> <433294C3.1090801@php.net>
Date: Thu, 22 Sep 2005 13:52:33 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: PDO questions
From: r.korving@xit.nl ("Ron Korving")

> Ron Korving wrote:
>
> > 1) Does unsetting $stmt trigger a closeCursor() as well? I assume so,
but
> > the article doesn't mention it. It only talks about the importance of
> > calling that method.
>
> yes this is done automatically ..

Great :)

> > 2) Could it be a good idea (performance wise) and possible in the first
> > place to maintain a pool of prepared statements? Something like this:
>
> This should be done on the RDBMS end. I havent looked at how PDO does
> this in detail, but it would be nice to get some more control over this.
>   Some RDBMS will pool this automatically, some do not (AFAIK pgsql will
> always create a new statement instead of returning a handle to an
> existing statement). There is a reason why you may want more control
> over this. One of the key aspects of a prepared statement is that you
> safe time due to not having to build a query plan on every execution.
> This may bite you however if you prepare a statement and then things
> change within the database that would make it more feasible to use a new
> plan.

It would be very nice if this was indeed done by the RDBMS. That would mean
you don't have to "remember" any prepared statements yourself and would
definately benefit the performance a great deal.

> > 3) Wouldn't it be nice if you could do a $stmt->execute("foo", "bar");
> > (numeric parameters) instead of $stmt->execute(array("foo", "bar")); ?
>
> I think this would severely hurt the extensibility of the API not only
> for PDO itself, but also for people who want to transparently extend the
> API.

Good point, I take that back.

> regards,
> Lukas

Thanks,

Ron


________________________________________
Scanned and protected by SecureMail v2.2
http://www.axit.nl