Lukas Smith wrote:
> Yasuo Ohgaki wrote:
>
>> @ operator is ok, but usually @ operator is not recommenned.
>> Don't you think so? I try not to use @ as much as possible.
>>
>> pg_execute() does not have to raise error just like file_exists().
>> It may be good idea to raise error when connection is bad, etc.
>
> the problem is a limitation in pgsql and hiding this fact imho causes
> more problems than it solves, especially since pgsql will eventually
> solve this limitation (i hear 8.2 will solve this).
I heard postgresql people intends
just execute PQexecute, if it fails, prepare
since this is most natural way to handle persistent database connections.
8.2 backends will have view for currently registered plans. Since backends
have query plans, clients must requests send over net work just to see if
plan is defined or not.
i.e.
if (!pg_execute('plan')) {
pg_prepare('plan', sql);
pg_execute('plan');
}
Looking up plan data in backends is just a waste of resources even when 8.2
is available.
>
> another solution that does of course add a fixed amount of overhead is
> to simply prepare the statement again before you enter the loop. you
> will then only have to supress a single call to pg_prepare().
pg_prepare() also raises E_WARNING when plan is already defined, thus
calling pg_prepare() is not an option. PQprepare is not light function also.
It has to initialize SQL parser etc, while PQexecute just looks up plan
names when it fails.
When app uses PHP's persistent connections (or pgpooled connections),
programmers
can take advantages of prepared statements performance benefits.
i.e. PostgreSQL have to compile SQL only once for a web server thread /process.
I don't see any down sides removing pg_execute E_WARNING for duplicate plans.
I will restore pg_execute E_WARING except already defined plans.
Is this satisfactory?
--
Yasuo Ohgaki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
