Re: [PHP-DEV] pdo: binding variables supplied to execute() is NotVeryUseful(tm)...
Am 31.03.2005 um 17:28 schrieb Marcus Boerger: Hello Thies, Friday, March 25, 2005, 1:55:30 PM, you wrote: and this is 'cause pdo _expects_ the user to prefix the bound variables with a colon. grr... ppls, lets change it before it's too late. this "tiny bit" makes binding harder than it should be, and we all know and understand that all user of php should use bound variables all the time! suggestion: auto-trim a leading colon from the internal binding tables. that way "oldish" code would not break... re, thies PS: looking into that right now - hopefully "patch follows";-) We could easily add this behavior and i think it makes somewhat sense. It just looks a bit like __wakepup/__sleep. The only 'but' is that i suggest the behavior has its own method like 'bindParamArray'. If you cannot work out a patch feel free to contact me. Maybe i'll find some time during the conf. hey marcus! i don't quite understand the relation to sleep/wakeup here (i'm not reading all the php lists, maybe you could point me to the right thread?) adding a new 'bindParamArray' with different semantics doesn't really make things easier. and i think we should have once consistent parameter-bind interface: - a method bindParam - an optinal associative array passed to execute. all those functions expect to bind a to a statement. this should work both with or without a leading colon. by the way (just checked) - this is how the "native" oracle-oci binding functions work. so oracle decided to make the colon in front of the placeholder for bind optional. at the end of the day you can only bind to a placeholder defined in your sql-statement. in the sql you have to "mark" the placeholder by prepending a colon - but for the bind you really don't need the colon. really! so - again - lets make the colon *optional* - everywhere we allow binding in PDO! re, thies -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pdo: binding variables supplied to execute() is NotVeryUseful(tm)...
Yep, will do. On Apr 1, 2005 3:13 AM, Thies C. Arntzen <[EMAIL PROTECTED]> wrote: > so - again - lets make the colon *optional* - everywhere we allow > binding in PDO! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Contributing
//Hi,// // //I am interested in contributing to PHP now that I have been using it for 2 years or so. I was wondering how to get involved. I am not able to help with the development of the language itself but I would be interested in verifying bugs, writing documentation and/or maintaining the website.// // //How should I go about getting involved?// // //Thanks,// David Mytton// -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Contributing
David Mytton wrote: > //Hi,// > // > //I am interested in contributing to PHP now that I have been using it > for 2 years or so. I was wondering how to get involved. I am not able to > help with the development of the language itself but I would be > interested in verifying bugs, writing documentation and/or maintaining > the website.// > // > //How should I go about getting involved?// > // > //Thanks,// > > David Mytton// The easiest way to contribute is to answer questions on a newsgroup like this one (or even php-general). If you're serious about helping with the documentation effort you should check out the newsgroup php-doc. -- Teach a man to fish... NEW? | http://www.catb.org/~esr/faqs/smart-questions.html STFA | http://marc.theaimsgroup.com/?l=php-general&w=2 STFM | http://php.net/manual/en/index.php STFW | http://www.google.com/search?q=php LAZY | http://mycroft.mozdev.org/download.html?name=PHP&submitform=Find+search+plugins signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] pdo: binding variables supplied to execute() is NotVeryUseful(tm)...
Hello Thies, Friday, April 1, 2005, 3:13:10 AM, you wrote: > Am 31.03.2005 um 17:28 schrieb Marcus Boerger: >> Hello Thies, >> >> Friday, March 25, 2005, 1:55:30 PM, you wrote: >> >>> and this is 'cause pdo _expects_ the user to prefix the bound >>> variables >>> with a colon. grr... >> >>> ppls, lets change it before it's too late. this "tiny bit" makes >>> binding >>> harder than it should be, and we all know and understand that all user >>> of php should use bound variables all the time! >> >>> suggestion: auto-trim a leading colon from the internal binding >>> tables. >>> that way "oldish" code would not break... >> >> >>> re, thies >> >>> PS: looking into that right now - hopefully "patch follows";-) >> >> >> We could easily add this behavior and i think it makes somewhat sense. >> It just looks a bit like __wakepup/__sleep. The only 'but' is that i >> suggest the behavior has its own method like 'bindParamArray'. If you >> cannot work out a patch feel free to contact me. Maybe i'll find some >> time during the conf. > hey marcus! > i don't quite understand the relation to sleep/wakeup here (i'm not > reading all the php lists, maybe you could point me to the right > thread?) > adding a new 'bindParamArray' with different semantics doesn't really > make things easier. and i think we should have once consistent > parameter-bind interface: > - a method bindParam > - an optinal associative array passed to execute. > all those functions expect to bind a to a statement. > this should work both with or without a leading colon. > by the way (just checked) - this is how the "native" oracle-oci binding > functions work. so oracle decided to make the colon in front of the > placeholder for bind optional. at the end of the day you can only bind > to a placeholder defined in your sql-statement. in the sql you have to > "mark" the placeholder by prepending a colon - but for the bind you > really don't need the colon. really! > so - again - lets make the colon *optional* - everywhere we allow > binding in PDO! > re, thies hmmm, this is just a copy'n'paste mistake somehow -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Contributing
On Fri, 1 Apr 2005, Jason Barnett wrote: > David Mytton wrote: > > //Hi,// > > // > > //I am interested in contributing to PHP now that I have been using it > > for 2 years or so. I was wondering how to get involved. I am not able to > > help with the development of the language itself but I would be > > interested in verifying bugs, writing documentation and/or maintaining > > the website.// > > // > > //How should I go about getting involved?// > > // > > //Thanks,// > > > > David Mytton// > > The easiest way to contribute is to answer questions on a newsgroup like > this one (or even php-general). If you're serious about helping with > the documentation effort you should check out the newsgroup php-doc. Also, write normal emails - without all those slashes and a 9 line sig. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ANNOUNCE] PHP 4.3.11 & 5.0.4 Released!
On Thu, Mar 31, 2005 at 04:50:22PM -0500, Ilia Alshanetsky <[EMAIL PROTECTED]> is thought to have said: > The PHP Development Team would like to announce the immediate release of > PHP 4.3.11 and 5.0.4. These are maintenance releases that in addition > to fixing over 70 non-critical bugs, address several security issues. > The addressed security issues include fixes to the exif and fbsql > extensions, as well as fixes to unserialize(), swf_definepoly() and > getimagesize(). Perhaps in the future issues involving security fixes could include a bit more detail so those of us running critical production environments can make a determination of scope of the problem? Things like 'you must have this extension enabled to be vulnerable' and 'vulnerability results in a denial of service (or remote command execution, or local privilege escalation, etc)' would be very useful for sysadmins. -- Tabor J. Wells [EMAIL PROTECTED] Fsck It! Just another victim of the ambient morality -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: ZendEngine2 / Zend.m4 php-src acinclude.m4
On Feb 27, 2005 8:19 AM, Jani Taskinen <[EMAIL PROTECTED]> wrote: > On Sun, 27 Feb 2005, Sebastian Bergmann wrote: > > > Jani Taskinen wrote: > >> AC_MSG_WARN([You will need bison 1.28, 1.35, 1.75 or 1.875 if you want > > > > bison 2.0 also works (at least for me). > > Let's not add that to the list yet. Wait couple of months. :) > > --Jani FWIW, bison 2.0 also works fine for me on Fedora Core 4test1. (It's the default bison installed.) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pdo: binding variables supplied to execute() is NotVeryUseful(tm)...
Wez Furlong wrote: Yep, will do. I dont want to pretend that this change should open the flood gates for radical changes. However there are still a few minor points beyond the bindParam() that may need minor adjustments. Some of them can be added later of course .. 1) DSN http://oss.backendmedia.com/index.php?area=PDO&page=DSN It would be nice to be able as an array and for the string format it would be nice to also have the option of using the established PEAR DSN format 2) exec() http://oss.backendmedia.com/index.php?area=PDO&page=exec It may be nice to have a simple one shot prepared query to be able to do a prepare/execute in one call. 3) setAttribute/getAttribute http://oss.backendmedia.com/index.php?area=PDO&page=setAttribute Some of the "attributes" are actually more like options that can be defined by the user. Others are defined by the client and yet others are defined by the server and cannot be changed by the user. I think atleast the user definable options should be moved to a separate setOption/getOption set of methods. 4) minor API stuff in the fetch methods I think it would be clearer to call the fetch() method fetchRow() because that is what the method does. I also dont think we should default to PDO_FETCH_BOTH. It may also be a nice touch towards PEAR::[M]DB[2] to rename the fetchSingle() method to fetchOne(). Its also more clearer since fetchSingle() might as well imply a single row. Fetching a single row should probably be handled by a fetchCol() method. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.0.4 PEAR issue
Folks, We have a bit of a situation with the PEAR distro that's embedded in 5.0.4. It's missing the RunTest.php file, so PEAR doesn't install. The options we have, as far as I can tell, are: [a] Re-release 5.0.4 with that file [b] Release 5.0.5 with that file (seems a bit too aggressive considering there are no code changes, and may cause confusion) [c] Instruct people to install PEAR from http://go-pear.org I lean towards option [a]. Thoughts? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0.4 PEAR issue
I On Apr 1, 2005 5:00 PM, Zeev Suraski <[EMAIL PROTECTED]> wrote: > The options we have, as far as I can tell, are: > > [a] Re-release 5.0.4 with that file > [b] Release 5.0.5 with that file (seems a bit too aggressive considering > there are no code changes, and may cause confusion) > [c] Instruct people to install PEAR from http://go-pear.org > [a] seems like the most sane choice to me. I would also just place a note on the site (maybe the download page?) explaining what happened and letting people know why the files changed. -- Adam C. Greenfield <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.0.4 PEAR issue
On Sat, 02 Apr 2005 00:00:18 +0200 [EMAIL PROTECTED] (Zeev Suraski) wrote: > Folks, > > We have a bit of a situation with the PEAR distro that's embedded > in 5.0.4. It's missing the RunTest.php file, so PEAR doesn't > install. > > The options we have, as far as I can tell, are: > > [a] Re-release 5.0.4 with that file > [b] Release 5.0.5 with that file (seems a bit too aggressive > considering there are no code changes, and may cause confusion) > [c] Instruct people to install PEAR from http://go-pear.org > > I lean towards option [a]. Thoughts? Agreed for [a]. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.0.4 PEAR issue
Zeev Suraski wrote: Folks, We have a bit of a situation with the PEAR distro that's embedded in 5.0.4. It's missing the RunTest.php file, so PEAR doesn't install. The options we have, as far as I can tell, are: [a] Re-release 5.0.4 with that file [b] Release 5.0.5 with that file (seems a bit too aggressive considering there are no code changes, and may cause confusion) [c] Instruct people to install PEAR from http://go-pear.org I lean towards option [a]. Thoughts? I think [a] is the best choice as well, perhaps with a brief note at php.net? This is my fault and is no April Fool's joke. The problem was that RunTest.php was sitting in my local checkout but was not properly cvs added, so my install tests worked just fine. This has been corrected. To avoid this for the future, I'm brainstorming ideas for a script that can be used to sync with released PEAR packages so that pear can be removed from php-src altogether in CVS, and simply synced as part of a cron job for the snaps machines. Any advice or admonitions would be appreciated. Greg Pierre: can we work on this in tandem? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.0.4 PEAR issue
Would 5.0.4pl1 be inappropriate? Two different versions of 5.0.4 seems odd, and 5.0.5 seems too drastic as you mentioned. Otherwise, IMHO, just make a brief announcement, point them to go-pear, and go through a normal 5.0.5 release cycle in a few weeks once a few more fixes make it in. Humbly, this isn't a big problem. Best, Mike Robinson Zeev Suraski wrote: > Folks, > > We have a bit of a situation with the PEAR distro that's > embedded in 5.0.4. It's missing the RunTest.php file, so > PEAR doesn't install. > > The options we have, as far as I can tell, are: > > [a] Re-release 5.0.4 with that file > [b] Release 5.0.5 with that file (seems a bit too aggressive > considering there are no code changes, and may cause > confusion) [c] Instruct people to install PEAR from http://go-pear.org > > I lean towards option [a]. Thoughts? > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0.4 PEAR issue
Option [a] seems like the most logical thing to do, would probably work the best. It might be nice to note on php.net somewhere right now before this is fixed that PEAR will not install. The options we have, as far as I can tell, are: [a] Re-release 5.0.4 with that file [b] Release 5.0.5 with that file (seems a bit too aggressive considering there are no code changes, and may cause confusion) [c] Instruct people to install PEAR from http://go-pear.org I lean towards option [a]. Thoughts? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.0.4 PEAR issue
Hi I think a 5.0.4.1 would be the best way to go (not sure what versioning to use), as there are no real code changes to justify a 5.05. You could then provide a patch with notes for those with 5.04 installed or they could compile 5.0.4.1 I'd suggest if you rerelease the 5.0.4 as "5.0.4" then those with 5.0.4 installed will become a bit confused as to what they have installed (unless they do the checksum check). As for the CVS issue, I find in the code I write, doing a "cvs diff ." on my local directory tells me if anything is not in the repository, then I can cvs add and cvs commit once done. I then tag with the version number, roll a release package and install it on a pre production machine. Once the package is tested on a pre production machine I know that it will be ok in userspace -- if not I source the problem and roll a pre producton package again. HTH James On Apr 1, 2005 8:25 PM, Matthew Fonda <[EMAIL PROTECTED]> wrote: > > Option [a] seems like the most logical thing to do, would probably work the > best. It might be nice to note on php.net somewhere right now before this is > fixed that PEAR will not install. > > > The options we have, as far as I can tell, are: > > > > [a] Re-release 5.0.4 with that file > > [b] Release 5.0.5 with that file (seems a bit too aggressive considering > > there are no code changes, and may cause confusion) > > [c] Instruct people to install PEAR from http://go-pear.org > > > > I lean towards option [a]. Thoughts? > > > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: ZendEngine2 / Zend.m4 php-src acinclude.m4
On Fri, 1 Apr 2005, David Sklar wrote: On Feb 27, 2005 8:19 AM, Jani Taskinen <[EMAIL PROTECTED]> wrote: On Sun, 27 Feb 2005, Sebastian Bergmann wrote: Jani Taskinen wrote: AC_MSG_WARN([You will need bison 1.28, 1.35, 1.75 or 1.875 if you want bison 2.0 also works (at least for me). Let's not add that to the list yet. Wait couple of months. :) FWIW, bison 2.0 also works fine for me on Fedora Core 4test1. (It's the default bison installed.) Remind me about this when FC 4 is released as 'stable' :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
