Yasuo Ohgaki wrote:
> 3) add bool parameter to pg_execute()
>e.g. pg_execute(resource connection, string stmtname, array params, bool
> ignore_error)
how would you intent to implement this?
AFAIK there is currently no catalog to find out the prepared statements
in the current sessions (I hea
Lukas Smith wrote:
> Yasuo Ohgaki wrote:
>
>> 3) add bool parameter to pg_execute()
>>e.g. pg_execute(resource connection, string stmtname, array params, bool
>> ignore_error)
>
> how would you intent to implement this?
> AFAIK there is currently no catalog to find out the prepared statement
Yasuo Ohgaki wrote:
> Lukas Smith wrote:
>> Yasuo Ohgaki wrote:
>>
>>> 3) add bool parameter to pg_execute()
>>>e.g. pg_execute(resource connection, string stmtname, array params, bool
>>> ignore_error)
>> how would you intent to implement this?
>> AFAIK there is currently no catalog to find o
This sounds like a really bad, backwards compatibility-breaking idea.
--Wez.
On 3/26/06, Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:
> Anyway, since there are no other comments, I'll get rid of
> the error from pg_execute. Since this is the most efficient
> way.
--
PHP Internals - PHP Runtime Develo
Agred, the patch should be reverted.
Edin
Wez Furlong wrote:
> This sounds like a really bad, backwards compatibility-breaking idea.
>
> --Wez.
>
> On 3/26/06, Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:
>
>>Anyway, since there are no other comments, I'll get rid of
>>the error from pg_execute. S
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 logi
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.
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.
Lukas Smith wrote:
> 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 yo
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
Regardless of whether it's a good idea or not, you should not just go
ahead and commit such a big behaviour change to the stable branch
during the release process.
Please revert your commit.
--Wez.
On 3/27/06, Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:
> Lukas Smith wrote:
> > So why dont you just
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 i
Wez Furlong wrote:
> Regardless of whether it's a good idea or not, you should not just go
> ahead and commit such a big behaviour change to the stable branch
> during the release process.
>
> Please revert your commit.
That's good point.
Any people should not depend on pg_execute's E_WARNING err
Yasuo Ohgaki wrote:
Wez Furlong wrote:
Regardless of whether it's a good idea or not, you should not just go
ahead and commit such a big behaviour change to the stable branch
during the release process.
Please revert your commit.
That's good point.
Any people should not depend on pg_execute's
Lukas Smith wrote:
> Sorry but your comparison to file_exists() is wrong. pg_execute()
> compares to something like include() if at all. Again I do want
> something like pg_is_prepared() but I rather wait until pgsql 8.2 where
> we get a proper native solution.
>
> For your case you should simply
15 matches
Mail list logo
