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
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
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
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
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:
> 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:
> 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
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
IMO, you're better off using stream_socket_server() and writing a
"real" daemon for that. Abusing fastcgi/cgi to work in that way is
only going to bite you in the ass.
--Wez
On 3/24/06, Matthew <[EMAIL PROTECTED]> wrote:
> I'm sorry if this is the wrong place for this post, I just don't know whe
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
That patch won't work if you build the posix extension shared and don't load it.
In addition, it's most likely too late to capture the real errno value
that you're looking for; PHP does a decent amount of stuff between the
time that the low level syscall fails and the point that you sample
it.
On
Hi all
Attached is a patch (against HEAD) to allow codes like:
$fp = @fopen("/unwritabledirectory/filename", "w");
if (!$fp) {
printf("The errornr was: %d", posix_get_last_error());
}
Fixes bug #36868
(If, for what ever reason, the patch doesn't come through:
http://php.is/bugs/36868/posix.patch
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
14 matches
Mail list logo
