Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22610
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4429DDC0.8080601@ohgaki.net>
Date: Wed, 29 Mar 2006 10:07:12 +0900
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Lukas Smith <lsmith@php.net>
CC: Wez Furlong <kingwez@gmail.com>,  internals@lists.php.net
References: <4425040E.60402@ohgaki.net> <44250532.7070509@php.net>	 <44275330.7050508@ohgaki.net> <44279BCB.1090105@php.net>	 <44280F96.3090600@ohgaki.net> <44281210.3000103@php.net>	 <442816CF.6040305@ohgaki.net> <4e89b4260603271311m50dcbdbbw8b29b0ddf712baf6@mail.gmail.com> <44288282.3070009@ohgaki.net> <4428FE9A.1020907@php.net>
In-Reply-To: <4428FE9A.1020907@php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: pg_execute error
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Lukas Smith wrote:
> Sorry but your comparison to file_exists() is wrong. pg_execute()
> compares to something like include() if at all. Again I do want
> something like pg_is_prepared() but I rather wait until pgsql 8.2 where
> we get a proper native solution.
> 
> For your case you should simply do:
> 
> // this will trigger an error if the query plan is already prepared
> // but we can ignore the error
> @pg_prepare($dbconn, 'myplan', $sql);
> for ($i = 0; $i < 10000; $i++) {
>   pg_execute($dbconn, 'myplan', $values);
> }
> 
> along with the necessary changes to your error handler you are all set.
> you only have a single error silenced call.
> 

You are missing points:

1. already defined planned query view requires overheads which
   requires network traffic.
2. @ is better to be avoided as much as possible.
3. All methods except following code requires some overheads.
4. "PQexecute, if it fails PQprepare" is the *intended* usage.
   (i.e. PQexecute should be used as PQisPrepared for usual app)
5. pg_execute's E_WARNING error for planned query is too much.
   (I think it's useful for debugging, though)

You may ignore extra pg_prepare or pg_is_prepared call over
postgresql connections, but I do not.

I didn't expect strong opposition removing E_WARNING from
pg_execute() since it seems it is the most preffered ways
to resolve issue.

Anyway, I will use @ for pg_execute(), since it's satisfactory
resolution also. fopen()'s E_WARNING is annoying. I just don't
like to have new function which behave like fopen().
-- 
Yasuo Ohgaki