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.
>
To make this issue clear, consider following code
for ($i = 0; $i < 10000; $i++) {
if (!pg_is_prepared('myplan')) { // suppose this function is there
pg_prepare('myplan', 'sql');
}
pg_execute('myplan', $values);
}
w/o the patch, pg_is_prepared() has to be called 10k times which
probably requires additional network traffic.
Best practice tells users should prepare statement before get into
transaction block and check transaction is committed or aborted
anyway. There are other reasons that transaction may fail as you
probably knew.
I disabled all E_WARNING, since all users are encouraged to check
the return status of pg_execute(), but other error may be caught
by pg_execute(). Is this enough?
--
Yasuo Ohgaki : [EMAIL PROTECTED] : http://www.ohgaki.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
