Yasuo Ohgaki wrote:
> Lukas Smith wrote:
>> Just to make it clear: calling pg_execute() on a not yet prepared
>> statement will cause your transaction to be rolled back on the next
>> commit. Encouraging the use of pg_execute() to find out of the statement
>> has been prepared is therefore wrong.
>>
>> Moreover by your logic we would need to remove E_WARNING's from php
>> entirely. Finally you can detect if a function call was called with
>> error suppression in your error handler and that is the appropriate
>> place to address your issue.
>
> This issue is like file_exists() raises E_ERROR, since
> PostgreSQL does not provide means to check if plan is
> already defined. i.e. design error for the function.
>
> Even if PostgreSQL provide view for already defined plans,
> selecting the view to check requires. It requires overheads
> which requires network traffic. Thus adding new feature to
> check if plan is defined is not good idea.
> i.e. DB is usually a bottle neck of web systems.
So why dont you just do @pg_execute() and in your error handler you can do:
function ErrorHandler($errno, $errstr, $errfile, $errline)
{
// ignore silenced function calls
if (!error_reporting()) {
return;
}
..
If you want a "beautiful" solution you will have to manage your prepared
statements in some persistant layer.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
