Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22597
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <44280F96.3090600@ohgaki.net>
Date: Tue, 28 Mar 2006 01:15:18 +0900
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
CC: internals@lists.php.net
References: <4425040E.60402@ohgaki.net> <44250532.7070509@php.net> <44275330.7050508@ohgaki.net> <44279BCB.1090105@php.net>
In-Reply-To: <44279BCB.1090105@php.net>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: pg_execute error
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

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.

-- 
Yasuo Ohgaki