Hi all
Resuming this once again after Anthony's blog post...
On 16/10/2014 18:10, Ferenc Kovacs wrote:
On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
I do agree that the default should probably be server-side since it is
the least surprising. We just need to make it
On 3 November 2014 09:18:08 GMT, Matteo Beccati p...@beccati.com wrote:
Hi all
Resuming this once again after Anthony's blog post...
On 16/10/2014 18:10, Ferenc Kovacs wrote:
On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
I do agree that the default should probably
On 03/11/2014 12:40, Rowan Collins wrote:
When using a one-shot call to query() with multiple statements (e.g.
create temp table; populate temp table; select results) it's actually
necessary with Postgres to switch on emulation, and for that
emulation to allow multiple queries even though the
On 03/11/2014 12:55, Matteo Beccati wrote:
[re: PQexec] Going from memory it is also used with
PGSQL_DISABLE_PREPARES (5.6+) if there are no bound parameters.
Actually, that was true only in the earlier versions of the feature.
I've decided not to do that to avoid behaviour changes and
2014.10.17. 6:51 ezt írta (Rasmus Lerdorf ras...@lerdorf.com):
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.
On 16/10/14 18:59, christopher jones wrote:
The MySQL team has been improving their server-side prepare code:
http://mysqlserverteam.com/re-factoring-some-internals-of-prepared-statements-in-5-7/
It may be worth clarifying some terms here since people are talking
about restrictions that MySQL
Am 17.10.2014 um 11:51 schrieb Lester Caine:
On 16/10/14 18:59, christopher jones wrote:
Ulf stated early on in this thread re MySQL
- statement and parameter are send to the server independently
- the server builds the final statement string
Is this ACTUALLY how it works? Since other
On 17/10/14 11:17, Ulf Wendel wrote:
Am 17.10.2014 um 11:51 schrieb Lester Caine:
On 16/10/14 18:59, christopher jones wrote:
Ulf stated early on in this thread re MySQL
- statement and parameter are send to the server independently
- the server builds the final statement string
Is
Am 17.10.2014 um 13:47 schrieb Lester Caine:
users know what they are getting and where the real security holes are.
Hmm, maybe, you could make this world a better one by contributing to
improve http://php.net/manual/en/pdo.prepared-statements.php ?
For the rest: the MySQL manual and the MySQL
On 17/10/14 13:20, Ulf Wendel wrote:
users know what they are getting and where the real security holes are.
Hmm, maybe, you could make this world a better one by contributing to
improve http://php.net/manual/en/pdo.prepared-statements.php ?
PDO does not support management of SQL differences
Am 17.10.2014 um 15:09 schrieb Lester Caine:
On 17/10/14 13:20, Ulf Wendel wrote:
users know what they are getting and where the real security holes are.
Hmm, maybe, you could make this world a better one by contributing to
improve http://php.net/manual/en/pdo.prepared-statements.php ?
PDO
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.
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
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 (
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
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
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,
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
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
Hi,
2012/6/28 Rasmus Lerdorf ras...@lerdorf.com:
On 06/27/2012 08:45 PM, Yasuo Ohgaki wrote:
Hi,
I forgot to mention MySQL's query cache.
This change may have negative performance impact, since prepared
query is not cached and native prepared query may not be used by
other requests.
Hi,
I forgot to mention MySQL's query cache.
This change may have negative performance impact, since prepared
query is not cached and native prepared query may not be used by
other requests.
It would be nice to have an option keeping prepared statement
when PDOStatement destroyed.
Regards,
--
On 06/27/2012 08:45 PM, Yasuo Ohgaki wrote:
Hi,
I forgot to mention MySQL's query cache.
This change may have negative performance impact, since prepared
query is not cached and native prepared query may not be used by
other requests.
That's not really true anymore. There are some
On Thu, 2012-06-21 at 22:35 -0400, Anthony Ferrara wrote:
Actually, the more I think about it, this would result in an
inadvertent API change. Right now, if you have a SQL syntax error, the
error would be thrown by -execute(). But with this change, the error
would be thrown by -prepare(). So
Am 20.06.2012 08:39, schrieb Pierre Joye:
hi Chris,
On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones
christopher.jo...@oracle.com wrote:
We should take this offline - I can see cases where I'd strongly disagree.
I see no reason to move a discussion offline or off list, this is a
topic
As it turns out, the testing of this is far more difficult than I
originally suspected. Not because it fails, but because emulated
queries were behaving badly to begin with, so a number of tests were
testing bad behavior. For example, bug 44327:
Actually, the more I think about it, this would result in an
inadvertent API change. Right now, if you have a SQL syntax error, the
error would be thrown by -execute(). But with this change, the error
would be thrown by -prepare(). So code that currently wraps execute()
but not prepare() with a
hi Chris,
On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones
christopher.jo...@oracle.com wrote:
We should take this offline - I can see cases where I'd strongly disagree.
I see no reason to move a discussion offline or off list, this is a
topic that interests many other readers or
On 06/16/2012 12:19 AM, Ulf Wendel wrote:
Am 15.06.2012 18:28, schrieb Christopher Jones:
On 06/15/2012 08:34 AM, Ulf Wendel wrote:
As long as client-side escaping is done properly, there is no
practical difference between the [client vs server -prepare]
approaches.
The big problem with
Hi,
I'm not opposed to this change, but I would like to give some ideas.
If I use PDO postgresql and prepared statement, it executes native
prepared query. However, prepared statement is released(removed)
when PDOStatement object is destroyed.
If PDO MySQL made like this, performance will not
Am 15.06.2012 18:28, schrieb Christopher Jones:
On 06/15/2012 08:34 AM, Ulf Wendel wrote:
As long as client-side escaping is done properly, there is no
practical difference between the [client vs server -prepare]
approaches.
The big problem with this line of reasoning is that the client must
Am 15.06.2012 03:01, schrieb Anthony Ferrara:
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
Am 15.06.2012 03:01, schrieb Anthony Ferrara:
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.
Does this need to be an RFC (should I draft
Chris,
Does this need to be an RFC (should I draft one)? Or can it just be
pulled as-is?
It needs an RFC because it needs to document whether or not the other
DB drivers should also be changed.
It's a PDO driver-specific change. So to me it's fairly straight
forward to see that no other
On 06/15/2012 09:36 AM, Anthony Ferrara wrote:
Chris,
Does this need to be an RFC (should I draft one)? Or can it just be
pulled as-is?
It needs an RFC because it needs to document whether or not the other
DB drivers should also be changed.
It's a PDO driver-specific change. So to me
Am 15.06.2012 18:36, schrieb Anthony Ferrara:
Chris,
Does this need to be an RFC (should I draft one)? Or can it just be
pulled as-is?
It needs an RFC because it needs to document whether or not the other
DB drivers should also be changed.
It's a PDO driver-specific change. So to me it's
Ulf,
It needs an RFC because it needs to document whether or not the other
DB drivers should also be changed.
It's a PDO driver-specific change. So to me it's fairly straight
forward to see that no other drivers need changing... It doesn't even
hit the mysql API level...
Not saying an RFC
Am 15.06.2012 19:31, schrieb Anthony Ferrara:
Ulf,
It needs an RFC because it needs to document whether or not the other
DB drivers should also be changed.
It's a PDO driver-specific change. So to me it's fairly straight
forward to see that no other drivers need changing... It doesn't even
Ulf,
My apologies. I mis-interpreted that reply.
I would commit, but I do not have commit access (no karma at all). I'm
going away for a few days, but when I get back I will send a separate
request to the list for karma.
Thanks,
Anthony
On Fri, Jun 15, 2012 at 1:55 PM, Ulf Wendel
No worries, Anthony!
Am 15.06.2012 21:15, schrieb Anthony Ferrara:
I would commit, but I do not have commit access (no karma at all). I'm
going away for a few days, but when I get back I will send a separate
request to the list for karma.
I see. It is not up to me to grant karma. I am not
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 (
40 matches
Mail list logo
