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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
