Re: Re: pg_execute error

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