Re: [PHP-DEV] RFC: Return Types Update
The RFC is very consistent. It proposes only a part of the desired type-hinting features, but this part is not questionable for me. +1 The implementation has some minor issues. Levi, if you won't object, I would like to play with implementation a bit, right before commit (if it accepted). Thanks. Dmitry. On Thu, Oct 16, 2014 at 8:39 AM, Levi Morrison levi_morri...@byu.edu wrote: Dear Internals, I finally have a working implementation for return types RFC[1] built on top of master. There are a few notes in the PR[2] about the implementation. I invite you all to review the PR and provide feedback. This means that I will soon move the return types RFC to voting phase. If you have not yet had time to review the RFC recently I invite you to do so now. The RFC has been slightly altered since the last discussion: - The RFC now targets PHP 7 (previously PHP 5.7). - There is a new section about disallowing return types on certain methods[4]. - The design and accompanying section of reflection[3] has been rewritten entirely. Regardless of the result of the RFC, I want to thank the many people who have been helpful to me as I have learned php-src and iterated over this RFC. [1]: https://wiki.php.net/rfc/returntypehinting [2]: https://github.com/php/php-src/pull/820 [3]: https://wiki.php.net/rfc/returntypehinting#reflection [4]: https://wiki.php.net/rfc/returntypehinting#methods_which_cannot_declare_return_types -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Return Types Update
Dmitry On 16 October 2014 08:44, Dmitry Stogov dmi...@zend.com wrote: The RFC is very consistent. It proposes only a part of the desired type-hinting features, but this part is not questionable for me. May I enquire what it misses out according to your ideal desired feature set? Just so that I/everyone is clear on what the limitations and potential areas for future expansion are, and to ensure nothing has been missed that could be included in this change without being too contentious. Apart from distinct features (e.g. scalar types) I'm not sure what is missing from the proposal, so I'd like to know what I'm missing. Also, just for the record, I am +1 on the RFC as it currently stands. Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Return Types Update
On Thu, Oct 16, 2014 at 6:39 AM, Levi Morrison levi_morri...@byu.edu wrote: Dear Internals, I finally have a working implementation for return types RFC[1] built on top of master. There are a few notes in the PR[2] about the implementation. I invite you all to review the PR and provide feedback. This means that I will soon move the return types RFC to voting phase. If you have not yet had time to review the RFC recently I invite you to do so now. The RFC has been slightly altered since the last discussion: - The RFC now targets PHP 7 (previously PHP 5.7). - There is a new section about disallowing return types on certain methods[4]. - The design and accompanying section of reflection[3] has been rewritten entirely. Regardless of the result of the RFC, I want to thank the many people who have been helpful to me as I have learned php-src and iterated over this RFC. +1 What I like about this RFC: * It only covers return types and nothing else (no nullable types, no scalar types, etc), thus avoiding unnecessary controversy. * It uses postfix type notation, which is great for `grep`, is compatible with Hack and avoids weird syntax with anonymous functions (and also with method generics, should they be introduced in the future). * Sticking with covariant return types, even though it was tricky to implement. Nikita
Re: [PHP-DEV] RFC: Return Types Update
On 16 Oct 2014, at 05:39, Levi Morrison levi_morri...@byu.edu wrote:
- There is a new section about disallowing return types on certain
methods[4].
Perhaps, along the same lines, we could error if you use a nonsensical type
hint for magic methods?
For example, allow this:
class FooBar {
public function __debugInfo(): array {
return [’test’];
}
}
But not this:
class FooBar {
public function __debugInfo(): callable {
return [’test’];
}
}
It’s not strictly necessary, but it would catch out bugs at “compile-time”
(i.e. script startup) rather than call-time.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hello all, I raised this topic on list over a year ago ( http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was determined that it wasn't time yet to disable prepared statement emulation for MySQL yet. However, Rasmus did mention that it was a possibility for 5.4 ( http://marc.info/?l=php-internalsm=130418875017027w=2 ). Since that ship has sailed, I submitted a pull request for trunk to change the default value of prepared statement emulation for MySQL. https://github.com/php/php-src/pull/108 https://bugs.php.net/bug.php?id=54638 Does this need to be an RFC (should I draft one)? Or can it just be pulled as-is? Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, do we want to change the default for this in PHP7? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: Return Types Update
Hi Chris, I meant scalar type hinting, nullable type hinting, may be even mixed type hinting... But, lets go by small steps to get all this finally accepted. Thanks. Dmitry. On Thu, Oct 16, 2014 at 1:35 PM, Chris Wright c...@daverandom.com wrote: Dmitry On 16 October 2014 08:44, Dmitry Stogov dmi...@zend.com wrote: The RFC is very consistent. It proposes only a part of the desired type-hinting features, but this part is not questionable for me. May I enquire what it misses out according to your ideal desired feature set? Just so that I/everyone is clear on what the limitations and potential areas for future expansion are, and to ensure nothing has been missed that could be included in this change without being too contentious. Apart from distinct features (e.g. scalar types) I'm not sure what is missing from the proposal, so I'd like to know what I'm missing. Also, just for the record, I am +1 on the RFC as it currently stands. Thanks, Chris
Re: [PHP-DEV] RFC: Return Types Update
I think the patch already does it (may be not for all magic methods).
Thanks. Dmitry.
On Thu, Oct 16, 2014 at 2:58 PM, Andrea Faulds a...@ajf.me wrote:
On 16 Oct 2014, at 05:39, Levi Morrison levi_morri...@byu.edu wrote:
- There is a new section about disallowing return types on certain
methods[4].
Perhaps, along the same lines, we could error if you use a nonsensical
type hint for magic methods?
For example, allow this:
class FooBar {
public function __debugInfo(): array {
return [’test’];
}
}
But not this:
class FooBar {
public function __debugInfo(): callable {
return [’test’];
}
}
It’s not strictly necessary, but it would catch out bugs at “compile-time”
(i.e. script startup) rather than call-time.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Return Types Update
On 10/16/2014 09:44 AM, Dmitry Stogov wrote: The RFC is very consistent. It proposes only a part of the desired type-hinting features, but this part is not questionable for me. +1 I second that emotion; +1. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Return Types Update
I very much like this — though I would say it was dependent on the nullable
types RFC (like splat and variadics were codependent).
While I would like to see the introduction of a void type, I understand and
respect the limitations on the RFC.
However, one thing that I do think is missing, is the equivalent of Hacks
`$this` return type. You have `self` and `parent`, but I think without a
`static` equivalent you can break things:
class foo {
static public function instanceOf(): self {
return new static();
}
}
class bar extends foo { }
foo::instanceOf(); // new foo, this is fine, returns `self`.
bar::instanceOf(); // new bar, no longer `self`
On Thu, Oct 16, 2014 at 12:39 AM, Levi Morrison levi_morri...@byu.edu
wrote:
Dear Internals,
I finally have a working implementation for return types RFC[1] built
on top of master. There are a few notes in the PR[2] about the
implementation. I invite you all to review the PR and provide
feedback.
This means that I will soon move the return types RFC to voting phase.
If you have not yet had time to review the RFC recently I invite you
to do so now.
The RFC has been slightly altered since the last discussion:
- The RFC now targets PHP 7 (previously PHP 5.7).
- There is a new section about disallowing return types on certain
methods[4].
- The design and accompanying section of reflection[3] has been
rewritten entirely.
Regardless of the result of the RFC, I want to thank the many people
who have been helpful to me as I have learned php-src and iterated
over this RFC.
[1]: https://wiki.php.net/rfc/returntypehinting
[2]: https://github.com/php/php-src/pull/820
[3]: https://wiki.php.net/rfc/returntypehinting#reflection
[4]:
https://wiki.php.net/rfc/returntypehinting#methods_which_cannot_declare_return_types
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Return Types Update
On Thu, 16 Oct 2014 18:39:06 +0400, Davey Shafik da...@php.net wrote:
I very much like this — though I would say it was dependent on the
nullable
types RFC (like splat and variadics were codependent).
While I would like to see the introduction of a void type, I understand
and
respect the limitations on the RFC.
However, one thing that I do think is missing, is the equivalent of Hacks
`$this` return type. You have `self` and `parent`, but I think without a
`static` equivalent you can break things:
class foo {
static public function instanceOf(): self {
return new static();
}
}
class bar extends foo { }
foo::instanceOf(); // new foo, this is fine, returns `self`.
bar::instanceOf(); // new bar, no longer `self`
Hi,
bar is considered as instance of foo so shouldn't be any problem.
Otherwise it would break LSP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Return Types Update
Hi Levi,
This RFC is pretty consistent, small and focused on a specific part of the
overall previously desired support.
I do think many more subsequent RFCs would come up after this one to expand
return typehint support, but as it stands right now is extremely good. Any
further inclusion would drastically delay possible acceptance of this RFC
and a possible withdrawn, since every piece left out are different
discussion points.
+1 so far.
[]s,
On Thu, Oct 16, 2014 at 10:46 AM, Nikita Nefedov inefe...@gmail.com wrote:
On Thu, 16 Oct 2014 18:39:06 +0400, Davey Shafik da...@php.net wrote:
I very much like this — though I would say it was dependent on the
nullable
types RFC (like splat and variadics were codependent).
While I would like to see the introduction of a void type, I understand
and
respect the limitations on the RFC.
However, one thing that I do think is missing, is the equivalent of Hacks
`$this` return type. You have `self` and `parent`, but I think without a
`static` equivalent you can break things:
class foo {
static public function instanceOf(): self {
return new static();
}
}
class bar extends foo { }
foo::instanceOf(); // new foo, this is fine, returns `self`.
bar::instanceOf(); // new bar, no longer `self`
Hi,
bar is considered as instance of foo so shouldn't be any problem.
Otherwise it would break LSP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Guilherme Blanco
MSN: guilhermebla...@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hello all, I raised this topic on list over a year ago ( http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was determined that it wasn't time yet to disable prepared statement emulation for MySQL yet. However, Rasmus did mention that it was a possibility for 5.4 ( http://marc.info/?l=php-internalsm=130418875017027w=2 ). Since that ship has sailed, I submitted a pull request for trunk to change the default value of prepared statement emulation for MySQL. https://github.com/php/php-src/pull/108 https://bugs.php.net/bug.php?id=54638 Does this need to be an RFC (should I draft one)? Or can it just be pulled as-is? Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, do we want to change the default for this in PHP7? Honestly, I am not sure about this anymore. There is a significant performance benefit in doing client-side prepares. Last year I attempted to switch to server-side prepares on Etsy's production servers but it added 30-40ms of page latency because of the extra round trips. And yes, we were doing too many queries, but I fear if we change this default people won't understand where this slowdown is coming from. Of course, in some rare cases using server-side prepares might speed things up because of prepared statement caching in the server, but I have yet to see a case where that caching outweighs the extra tcp roundtrip overhead. I do agree that the default should probably be server-side since it is the least surprising. We just need to make it very very clear in the upgrade doc that this change will likely slow down peoples' apps and show them how to turn client-side prepares back on. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hello all, I raised this topic on list over a year ago ( http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was determined that it wasn't time yet to disable prepared statement emulation for MySQL yet. However, Rasmus did mention that it was a possibility for 5.4 ( http://marc.info/?l=php-internalsm=130418875017027w=2 ). Since that ship has sailed, I submitted a pull request for trunk to change the default value of prepared statement emulation for MySQL. https://github.com/php/php-src/pull/108 https://bugs.php.net/bug.php?id=54638 Does this need to be an RFC (should I draft one)? Or can it just be pulled as-is? Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, do we want to change the default for this in PHP7? Honestly, I am not sure about this anymore. There is a significant performance benefit in doing client-side prepares. Last year I attempted to switch to server-side prepares on Etsy's production servers but it added 30-40ms of page latency because of the extra round trips. And yes, we were doing too many queries, but I fear if we change this default people won't understand where this slowdown is coming from. Of course, in some rare cases using server-side prepares might speed things up because of prepared statement caching in the server, but I have yet to see a case where that caching outweighs the extra tcp roundtrip overhead. I do agree that the default should probably be server-side since it is the least surprising. We just need to make it very very clear in the upgrade doc that this change will likely slow down peoples' apps and show them how to turn client-side prepares back on. -Rasmus I don't think we should remove the option, just change the defaults, and most people would be fine switching back to the emulation, but it should be their conscious decision imo. Currently many people aren't aware that they are using client side prepares, and they are pretty much ignore the fact, that they can be exposed to sql injections (for example via using mismatching client and server encodings or not properly quoting the identifiers: http://www.codeyellow.nl/identifier-sqli.html because they think that server side prepared statements would be immune to this kind of problems). I think it would be better to change the default in a major version, if the tradeoff is performance vs security, and if they think that they are okay with the emulation, they can change it back. ps: don't forget that some/many of our users are still using php on a single server setup, where the mysql connection is done through a unix socket instead of the network stack, so the roundtrip there will be even less noticable, and usually those are the kind of users, who need safe defaults because they can't afford to be aware or change settings/code for their apps. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Unicode support
Hello, I think that Rowan is right: PHP users need to manipulate grapheme clusters first (and code points in some rare situations). The fact that most of us live in a world were NFC composes all our characters only hides this reality. A typical use case is a template engine: nearly all string manipulations there need grapheme awareness: cutting strings for getting excerpt, inserting a space between every character, changing the case, etc. A typical use case for a PHP app. An other use case is if you want to implement text indexing in PHP: you need to normalize before indexing, handle case folding, and thus think in terms of graphemes. I'm not sure this is frequent in PHP though. Like already said, alongside with grapheme clusters, we should also deals with string matching: collations are out of scope, but normalization and case folding is in. Please do not forget the turkish alphabet https://github.com/nicolas-grekas/Patchwork-UTF8/blob/master/class/Patchwork/TurkishUtf8.php also... This is required IMHO to have what user expects for str_replace, strpos, strcmp, etc. I wrote a quite successful PHP lib to deal with this in PHP: https://github.com/nicolas-grekas/Patchwork-UTF8 My experience from this is the following: - dealing with grapheme clusters in current PHP is ok with grapheme_*() functions, but these require intl. It would be great to have them (or an equivalent) in core, - NFC normalization of all input is required to deal with string comparisons, so having Normalizer in core looks required also, - almost everybody uses mbstring when dealing with utf8 strings, but almost all cases should use a grapheme_*() instead. To be clear, I am suggesting that we aim to be the language which gets this right, where other languages get it wrong. Thank you for explaining this. I also think it could do better. I think Unicode-aware strrev() shouldn't be too complicated to do. Perl 6 identified the subject very well and invented what they call NFG, which is NFC + dynamic internal code points for non-composable grapheme clusters: http://docs.parrot.org/parrot/latest/html/docs/pdds/pdd28_strings.pod.html Maybe worth looking at? Cheers, Nicolas
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit :
On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Hello all,
I raised this topic on list over a year ago (
http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was
determined that it wasn't time yet to disable prepared statement
emulation for MySQL yet. However, Rasmus did mention that it was a
possibility for 5.4 (
http://marc.info/?l=php-internalsm=130418875017027w=2 ). Since that
ship has sailed, I submitted a pull request for trunk to change the
default value of prepared statement emulation for MySQL.
https://github.com/php/php-src/pull/108
https://bugs.php.net/bug.php?id=54638
Does this need to be an RFC (should I draft one)? Or can it just be
pulled as-is?
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hi,
do we want to change the default for this in PHP7?
Honestly, I am not sure about this anymore. There is a significant
performance benefit in doing client-side prepares. Last year I attempted
to switch to server-side prepares on Etsy's production servers but it
added 30-40ms of page latency because of the extra round trips. And yes,
we were doing too many queries, but I fear if we change this default
people won't understand where this slowdown is coming from.
Of course, in some rare cases using server-side prepares might speed
things up because of prepared statement caching in the server, but I
have yet to see a case where that caching outweighs the extra tcp
roundtrip overhead.
I do agree that the default should probably be server-side since it is
the least surprising. We just need to make it very very clear in the
upgrade doc that this change will likely slow down peoples' apps and
show them how to turn client-side prepares back on.
-Rasmus
I don't think we should remove the option, just change the defaults, and
most people would be fine switching back to the emulation, but it should be
their conscious decision imo.
Currently many people aren't aware that they are using client side
prepares, and they are pretty much ignore the fact, that they can be
exposed to sql injections (for example via using mismatching client and
server encodings or not properly quoting the identifiers:
http://www.codeyellow.nl/identifier-sqli.html because they think that
server side prepared statements would be immune to this kind of problems).
I think it would be better to change the default in a major version, if the
tradeoff is performance vs security, and if they think that they are okay
with the emulation, they can change it back.
ps:
don't forget that some/many of our users are still using php on a single
server setup, where the mysql connection is done through a unix socket
instead of the network stack, so the roundtrip there will be even less
noticable, and usually those are the kind of users, who need safe defaults
because they can't afford to be aware or change settings/code for their
apps.
Hi,
for me there is two usage of prepared statements :
#1 : safely handle variables
#2 : performance in batch traitments
The first one want emulated prepared statments and the second need true
prepared.
It's possible to add a simplier method for the first one case, and let
prepare() do a true prepare by default.
For example here we extends PDO to add the q() shortcut.
This shortcut basicaly do that :
public function q($statement, array $params)
{
$stmt = $this-prepare($statement, [PDO::MYSQL_ATTR_DIRECT_QUERY = true]);
return $stmt-execute($params);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On 10/16/14, 8:47 AM, Rasmus Lerdorf wrote: On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hello all, I raised this topic on list over a year ago ( http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was determined that it wasn't time yet to disable prepared statement emulation for MySQL yet. However, Rasmus did mention that it was a possibility for 5.4 ( http://marc.info/?l=php-internalsm=130418875017027w=2 ). Since that ship has sailed, I submitted a pull request for trunk to change the default value of prepared statement emulation for MySQL. https://github.com/php/php-src/pull/108 https://bugs.php.net/bug.php?id=54638 Does this need to be an RFC (should I draft one)? Or can it just be pulled as-is? Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, do we want to change the default for this in PHP7? Honestly, I am not sure about this anymore. There is a significant performance benefit in doing client-side prepares. Last year I attempted to switch to server-side prepares on Etsy's production servers but it added 30-40ms of page latency because of the extra round trips. And yes, we were doing too many queries, but I fear if we change this default people won't understand where this slowdown is coming from. Of course, in some rare cases using server-side prepares might speed things up because of prepared statement caching in the server, but I have yet to see a case where that caching outweighs the extra tcp roundtrip overhead. I do agree that the default should probably be server-side since it is the least surprising. We just need to make it very very clear in the upgrade doc that this change will likely slow down peoples' apps and show them how to turn client-side prepares back on. -Rasmus The MySQL team has been improving their server-side prepare code: http://mysqlserverteam.com/re-factoring-some-internals-of-prepared-statements-in-5-7/ Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On 16 October 2014 18:39:57 GMT+01:00, Olivier Bonvalet php-dev.l...@daevel.net wrote: Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit : On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com wrote: Hello all, I raised this topic on list over a year ago ( http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was determined that it wasn't time yet to disable prepared statement emulation for MySQL yet. However, Rasmus did mention that it was a possibility for 5.4 ( http://marc.info/?l=php-internalsm=130418875017027w=2 ). Since that ship has sailed, I submitted a pull request for trunk to change the default value of prepared statement emulation for MySQL. https://github.com/php/php-src/pull/108 https://bugs.php.net/bug.php?id=54638 Does this need to be an RFC (should I draft one)? Or can it just be pulled as-is? Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, do we want to change the default for this in PHP7? Honestly, I am not sure about this anymore. There is a significant performance benefit in doing client-side prepares. Last year I attempted to switch to server-side prepares on Etsy's production servers but it added 30-40ms of page latency because of the extra round trips. And yes, we were doing too many queries, but I fear if we change this default people won't understand where this slowdown is coming from. Of course, in some rare cases using server-side prepares might speed things up because of prepared statement caching in the server, but I have yet to see a case where that caching outweighs the extra tcp roundtrip overhead. I do agree that the default should probably be server-side since it is the least surprising. We just need to make it very very clear in the upgrade doc that this change will likely slow down peoples' apps and show them how to turn client-side prepares back on. -Rasmus I don't think we should remove the option, just change the defaults, and most people would be fine switching back to the emulation, but it should be their conscious decision imo. Currently many people aren't aware that they are using client side prepares, and they are pretty much ignore the fact, that they can be exposed to sql injections (for example via using mismatching client and server encodings or not properly quoting the identifiers: http://www.codeyellow.nl/identifier-sqli.html because they think that server side prepared statements would be immune to this kind of problems). I think it would be better to change the default in a major version, if the tradeoff is performance vs security, and if they think that they are okay with the emulation, they can change it back. ps: don't forget that some/many of our users are still using php on a single server setup, where the mysql connection is done through a unix socket instead of the network stack, so the roundtrip there will be even less noticable, and usually those are the kind of users, who need safe defaults because they can't afford to be aware or change settings/code for their apps. Hi, for me there is two usage of prepared statements : #1 : safely handle variables #2 : performance in batch traitments The first one want emulated prepared statments and the second need true prepared. Surely this is the other way around? Emulation has imperfect security, because it is basically a smarter version of magic quotes, e.g. the character encoding mismatch already mentioned. It's only advantage over real prepares is performance, if network latency is a significant factor. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.6.2 is available
Hello! The PHP development team announces the immediate availability of PHP 5.6.2. Four security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.2 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The full list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.6.2 Ferenc Kovacs Julien Pauli
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On 10/16/2014 02:38 PM, Morgan Tocker wrote: The more clear cases would be: - The prepared statement is reused enough times that the initial extra round trip can be amortized. - If large place-holder values can be sent direct to the server without having to be escaped or parsed. For example reading a file directly into the contents of a column to insert. Other than large batch backfill jobs it is not very common to issue the same query enough times to overcome the connection overhead. At least not in code I have worked with. But I am glad to see that there is work being done on it. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.34 Released
Hello! The PHP development team announces the immediate availability of PHP 5.4.34. 6 security-related bugs were fixed in this release, including fixes for CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670. Also, a fix for OpenSSL which produced regressions was reverted. All PHP 5.4 users are encouraged to upgrade to this version. For source downloads of PHP 5.4.34 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.4.34 Stanislav Malyshev PHP 5.4 RM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
On 10/16/2014 09:10 AM, Ferenc Kovacs wrote: I don't think we should remove the option, just change the defaults, and most people would be fine switching back to the emulation, but it should be their conscious decision imo. Currently many people aren't aware that they are using client side prepares, and they are pretty much ignore the fact, that they can be exposed to sql injections (for example via using mismatching client and server encodings or not properly quoting the identifiers: http://www.codeyellow.nl/identifier-sqli.html because they think that server side prepared statements would be immune to this kind of problems). I think you have the wrong idea here. That link you pointed to talks about SQLi in identifiers. Server-side prepares are just as vulnerable to this, so switching from client-side to server-side does nothing to make this safer. As far as a charset mismatch between the client and the server when it comes to preparing query values, PDO's implementation handles that. You need a connection handle to do a prepare so we know the charset and take that into account. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
