I have a suggestion that is related a little to my bug report #38394 (
http://bugs.php.net/bug.php?id=38394).
It's about the execution of a prepared statement.
Let's say we have a prepared statement for
UPDATE table SET field1 = :field1, field2 = :field3 WHERE id = :id
in order to execute it
On Wed, 9 Aug 2006, Marian Kostadinov wrote:
I have a suggestion that is related a little to my bug report #38394 (
http://bugs.php.net/bug.php?id=38394).
It's about the execution of a prepared statement.
Let's say we have a prepared statement for
UPDATE table SET field1 = :field1,
Derick Rethans wrote:
On Wed, 9 Aug 2006, Marian Kostadinov wrote:
But that is not executed because we have some additional key/value pairs.
So the idea is to allow this. Also I suggest we allow using object along
with an array. This is a common situation also.
Actually, it is dependent on
Michael Wallner wrote:
I planned to upgrade it to something similar
like http_encoding_api.
So, are there any objections on that?
Regards,
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi.
I'm getting a crash with the new Win32 Snapshot - PHP 5.2.0RC2-dev
(cli) (built: Aug 9 2006 08:20:48) / PHP Version 5.2.0RC2-dev Build
Date Aug 9 2006 08:15:12 (for ISAPI)
(From DrWatson for CLI)
AppName: php.exe AppVer: 5.2.0.0 ModName: php5ts.dll
ModVer: 5.2.0.0 Offset:
Michael Wallner wrote:
Derick Rethans wrote:
On Wed, 9 Aug 2006, Marian Kostadinov wrote:
But that is not executed because we have some additional key/value pairs.
So the idea is to allow this. Also I suggest we allow using object along
with an array. This is a common situation also.
Yes, that's my idea - to ignore keys that are not defined as placeholder.
And not only for objects but for arrays also.
2006/8/9, Lukas Smith [EMAIL PROTECTED]:
Michael Wallner wrote:
Derick Rethans wrote:
On Wed, 9 Aug 2006, Marian Kostadinov wrote:
But that is not executed because we
Marian Kostadinov wrote:
Yes, that's my idea - to ignore keys that are not defined as placeholder.
And not only for objects but for arrays also.
I do not know the implementation in PDO, but the implementation I made
in MDB2 only tries to parse the placeholders if it has to emulate or
How is that? You can't get any feedback from PHP (except, now, by
installing/writing an extension) about how far along the upload is - no
matter how much JavaScript you use. And the browser won't tell you.
Some people have scanned the /tmp directory for possible PHP uploads,
but this
The patch to support this is in PHP 5.2 CVS now.
Unknown W. Brackets wrote:
How is that? You can't get any feedback from PHP (except, now, by
installing/writing an extension) about how far along the upload is - no
matter how much JavaScript you use. And the browser won't tell you.
Some
If you set post_max_size to 0, you can parse the post data yourself from
php://input. Combine that with the Content-Length value from
apache_request_headers() and you have everything you need for a progress
monitor.
I don't mean to detract from the hopefully soon-to-come support in the
core,
Translatting
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, refresh my memory, what are we talking about here?
-A
On Aug 9, 2006, at 3:38 AM, Michael Wallner wrote:
Michael Wallner wrote:
I planned to upgrade it to something similar
like http_encoding_api.
So, are there any objections on that?
Regards,
--
Michael
--
PHP Internals - PHP
Andrei Zmievski wrote:
Sorry, refresh my memory, what are we talking about here?
I was planning to port
http://cvs.php.net/pecl/http/http_encoding_api.c?view=markup
to ext/zlib. It would provide a concise zlib API for PHP and uses a more
performant iterative inflate approach instead of the
Okay, so this doesn't have much to do with Unicode stuff. I think if
you port it, calling it something other than http_encoding would be a
good idea, to avoid confusion with other encoding settings.
-Andrei
On Aug 9, 2006, at 9:13 AM, Michael Wallner wrote:
Andrei Zmievski wrote:
Sorry,
Andrei Zmievski wrote:
Okay, so this doesn't have much to do with Unicode stuff. I think if you
port it, calling it something other than http_encoding would be a good
idea, to avoid confusion with other encoding settings.
Yeah, of course I thought of php_zlib_*.
Thanks,
--
Michael
--
PHP
Arpad Ray wrote:
If you set post_max_size to 0, you can parse the post data yourself from
php://input. Combine that with the Content-Length value from
apache_request_headers() and you have everything you need for a progress
monitor.
Of course - this is entirely irrelevant if the client uses
Developing the PHP language itself. Beginning with fixing the Bug #28227, so
that PHP can work with any webserver which conforms to the CGI specification.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 09.08.2006 22:20, Mike Scarborough wrote:
Developing the PHP language itself. Beginning with fixing the Bug #28227, so
that PHP can work with any webserver which conforms to the CGI specification.
The common way to start developing PHP is to send patches to the internals@,
there are
I had thought that was only for extensions; is there something in the
userspace too (without writing/installing an extension)?
Thanks,
-[Unknown]
Original Message
The patch to support this is in PHP 5.2 CVS now.
Unknown W. Brackets wrote:
How is that? You can't get any
Fair enough. I was under the (now obviously wrong) impression that
setting post_max_size to 0 wouldn't let me get to the post data.
But that's still setting you dependent on it being Apache. I would need
(if I were to add this feature to any of my software) to write this in
code that can
21 matches
Mail list logo
