Re: Re: pg_execute error

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