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 unplea
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 t
On 3 November 2014 09:18:08 GMT, Matteo Beccati 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
>wrote:
>>> I do agree that the default should probably be server-side since it
>
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 wrote:
>> 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 cle
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 ?
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 difference
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 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 strin
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
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 MyS
2014.10.17. 6:51 ezt írta ("Rasmus Lerdorf" ):
>
> 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.
> > Currentl
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
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 e
On 16 October 2014 18:39:57 GMT+01:00, Olivier Bonvalet
wrote:
>Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit :
>> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf
>wrote:
>>
>> > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
>> > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara
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
wrote:
Hello all,
I raised this topic on list over a year ago (
http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was
determined that it was
Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit :
> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf wrote:
>
> > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
> > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara
> > > wrote:
> > >
> > >> Hello all,
> > >>
> > >> I raised this topi
On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf wrote:
> On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
> > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara
> > wrote:
> >
> >> Hello all,
> >>
> >> I raised this topic on list over a year ago (
> >> http://marc.info/?l=php-internals&m=1304176465077
On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
> On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara
> wrote:
>
>> Hello all,
>>
>> I raised this topic on list over a year ago (
>> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was
>> determined that it wasn't time yet to disable prepar
On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara
wrote:
> Hello all,
>
> I raised this topic on list over a year ago (
> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was
> determined that it wasn't time yet to disable prepared statement
> emulation for MySQL yet. However, Rasmus
Hi,
2012/6/28 Rasmus Lerdorf :
> 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 n
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 lim
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,
--
Y
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().
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 t
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:
https://github.com/ircmaxell/php-src/blob/master/ext
Am 20.06.2012 08:39, schrieb Pierre Joye:
hi Chris,
On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones
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 read
hi Chris,
On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones
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 developers.
Cheers,
--
Pierre
@pier
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 in
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 th
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
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 tha
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 wrote:
> Am
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
hi
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...
>>
>
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 f
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 it'
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
Am 15.06.2012 03:01, schrieb Anthony Ferrara:
I raised this topic on list over a year ago (
http://marc.info/?l=php-internals&m=130417646507744&w=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
Am 15.06.2012 03:01, schrieb Anthony Ferrara:
I raised this topic on list over a year ago (
http://marc.info/?l=php-internals&m=130417646507744&w=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
possibi
Hello all,
I raised this topic on list over a year ago (
http://marc.info/?l=php-internals&m=130417646507744&w=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=p
40 matches
Mail list logo