hi,
It is also important to keep in mind that there are a growing
alternative to Oracle's mysql, so focusing only on Oracle plans is not
necessary a good thing to do.
That being said, it seems that we have an agreement to change this
behavior in trunk. It is a documentation matter then. There is
On 30.04.2011, at 22:05, Ben Schmidt wrote:
> This adds a certain ambiguity to document creation if it is used, but it
> does add functionality not currently there. I guess it's only worth
> doing if there are specs out there in the wild that (wrongly IMHO)
> require "unqualified" names in XMLName
On Sat, Apr 30, 2011 at 10:05 PM, Clint Byrum wrote:
> Excerpts from Rasmus Lerdorf's message of Sat Apr 30 10:53:30 -0700 2011:
> > On 04/30/2011 10:36 AM, Stas Malyshev wrote:
> > > Hi!
> > >
> > >> Do you realize why we did this in the first place? The common versions
> > >> of MySQL in use ou
Excerpts from Rasmus Lerdorf's message of Sat Apr 30 10:53:30 -0700 2011:
> On 04/30/2011 10:36 AM, Stas Malyshev wrote:
> > Hi!
> >
> >> Do you realize why we did this in the first place? The common versions
> >> of MySQL in use out there are not very clever when it comes to the
> >> native prepar
Again, xmlns="" puts an element in no namespace. That already works in
SimpleXML. There is no issue here that needs fixing.
IIUC, the OP doesn't want the element to be in no namespace, but wants
it to be in the default namespace, but unprefixed.
I have already laid out my reasons for believing
On Sat, Apr 30, 2011 at 9:01 PM, Rasmus Lerdorf wrote:
> On 04/30/2011 11:59 AM, Anthony Ferrara wrote:
>
>> I'm not arguing if there weren't reasons for implementing it this way.
>> I am arguing if they are good enough reasons to justify the security
>> impact. It's not my decision (and I resp
Correct. But prior to 5.3.6 it was not possible to have PDO and MySQL
agree on the character set (at least without having root access to the
server). And after 5.3.6, the DSN *must* include the charset
parameter to make them agree. The common technique of setting the
charset via SET NAMES (which
On 04/30/2011 12:05 PM, Anthony Ferrara wrote:
Native prepared statements will completely protect you from injection
via any of the bound parameters. The wire-level passage of the data
is completely different (and the data is sent by length, rather than
by deliminator). As an exercise, view the
Native prepared statements will completely protect you from injection
via any of the bound parameters. The wire-level passage of the data
is completely different (and the data is sent by length, rather than
by deliminator). As an exercise, view the traffic that's sent to the
server via Wireshark.
On 04/30/2011 11:59 AM, Anthony Ferrara wrote:
I'm not arguing if there weren't reasons for implementing it this way.
I am arguing if they are good enough reasons to justify the security
impact. It's not my decision (and I respect that), but I would stress
that what PDO is doing is not prepare
I'm not arguing if there weren't reasons for implementing it this way.
I am arguing if they are good enough reasons to justify the security
impact. It's not my decision (and I respect that), but I would stress
that what PDO is doing is not prepared statements or even
parameterized queries, and as
Actually, I'm talking out my ass. I know it's some version prior to 2005 and
I'm only guessing I meant SP3. I don't work on it, i've just heard the number 3
thrown around with it. I'll remove myself from the conversation before I make a
larger fool of myself :)
On Apr 30, 2011, at 1:44 PM, Fere
Sorry, you're right. It's 2000 service pack 3 :)
On Apr 30, 2011, at 1:44 PM, Ferenc Kovacs wrote:
>
>
> On Sat, Apr 30, 2011 at 8:16 PM, Matt Wilson wrote:
> Really would depend on the user. Part of my company still runs on SQLServer
> 2003, for instance...
>
> Corporate infrastructure rare
On Sat, Apr 30, 2011 at 8:16 PM, Matt Wilson wrote:
> Really would depend on the user. Part of my company still runs on SQLServer
> 2003, for instance...
>
> Corporate infrastructure rarely sees upgrades. Your cousin with the
> wordpress fetish, on the other hand...
>
>
what is SQLServer 2003?
ca
On 04/30/2011 11:10 AM, Ferenc Kovacs wrote:
with 5.0 EOL-ed for some time, and even the debian stable is running
5.1, I wonder how many of our user runs 5.0.
I'm not disagreeing, I just don't agree it is a bug against 5.3. There
were good reasons for the default at the time 5.3 was released.
Am 30.04.2011 20:10, schrieb Ferenc Kovacs:
>> People upgrade their databases even slower than they upgrade their PHP.
>>
> with 5.0 EOL-ed for some time, and even the debian stable is running 5.1, I
> wonder how many of our user runs 5.0.
and why should anybody wait for lazy people?
5.5 did not
Really would depend on the user. Part of my company still runs on SQLServer
2003, for instance...
Corporate infrastructure rarely sees upgrades. Your cousin with the wordpress
fetish, on the other hand...
On Apr 30, 2011, at 1:10 PM, Ferenc Kovacs wrote:
> On Sat, Apr 30, 2011 at 7:53 PM, Rasm
On Sat, Apr 30, 2011 at 7:53 PM, Rasmus Lerdorf wrote:
> On 04/30/2011 10:36 AM, Stas Malyshev wrote:
>
>> Hi!
>>
>> Do you realize why we did this in the first place? The common versions
>>> of MySQL in use out there are not very clever when it comes to the
>>> native prepared statement handlin
On 04/30/2011 10:36 AM, Stas Malyshev wrote:
Hi!
Do you realize why we did this in the first place? The common versions
of MySQL in use out there are not very clever when it comes to the
native prepared statement handling. First, there is no prepared
statement cache, so there is no benefit to d
Hi!
Do you realize why we did this in the first place? The common versions
of MySQL in use out there are not very clever when it comes to the
native prepared statement handling. First, there is no prepared
statement cache, so there is no benefit to doing them natively, but
Since 5.1.17 there i
Hi!
Which a good compiler with time to burn (think HipHop not Zend) could do, eg:
1. I think you overestimating the capabilities of HipHop, but I can be
mistaken.
2. HipHop represents a minority of use cases for PHP, I do not think it
is practical for PHP to target only monolitic pre-compile
On 29.04.2011, at 09:44, Tom Samplonius wrote:
>
>> While I think this would make SimpleXML more stupid, not less, as it
>> seems
>> braindead to me to allow users to create documents ambiguously and/or
>> which
>> essentially violate the XML namespace spec, I think the way to do
>
> Allowing c
On Sat, Apr 30, 2011 at 6:02 PM, Reindl Harald wrote:
>
> Am 30.04.2011 17:45, schrieb Ferenc Kovacs:
> > On Sat, Apr 30, 2011 at 5:39 PM, Rasmus Lerdorf
> wrote:
> >> Do you realize why we did this in the first place? The common versions
> of
> >> MySQL in use out there are not very clever when
On 04/30/2011 08:45 AM, Ferenc Kovacs wrote:
I disable query_cache on my machines, because it can cause performance
and stability issues.
http://www.mysqlperformanceblog.com/2011/04/10/should-we-give-a-mysqlquery-cache-a-second-chance/
Sure, there are some problems with it, but if you understan
Am 30.04.2011 17:45, schrieb Ferenc Kovacs:
> On Sat, Apr 30, 2011 at 5:39 PM, Rasmus Lerdorf wrote:
>> Do you realize why we did this in the first place? The common versions of
>> MySQL in use out there are not very clever when it comes to the native
>> prepared statement handling. First, there
On Sat, Apr 30, 2011 at 5:39 PM, Rasmus Lerdorf wrote:
> On 04/30/2011 08:13 AM, Anthony Ferrara wrote:
>
>> I have already reported this issue on the bug tracker:
>> http://bugs.php.net/bug.php?id=54638
>>
>> But I figured it would be good to start a discussion on it here. To
>> me, I consider
Well, the benefit to doing it natively would be to prevent SQL
Injection (which is possible now even with PDO's prepared statements).
As it stands now, it's quite possible to inject when using prepared
statements (easy <= 5.3.5, and possible >= 5.3.6, depending on
config). So basically the choice
On 04/30/2011 08:13 AM, Anthony Ferrara wrote:
I have already reported this issue on the bug tracker:
http://bugs.php.net/bug.php?id=54638
But I figured it would be good to start a discussion on it here. To
me, I consider this a pretty significant issue since it's not possible
to do true prepar
>
> I actually did consider adding support for an extended form of php://fd
> where one would specify the desired file descriptor: php://fd// fd>. It would call dup2 instead of dup.
>
> However, I got into some trouble on shutdown because this could cause
> stdout to be closed ahead of time and the
I have already reported this issue on the bug tracker:
http://bugs.php.net/bug.php?id=54638
But I figured it would be good to start a discussion on it here. To
me, I consider this a pretty significant issue since it's not possible
to do true prepared statements while using PDO. All the code to d
On Sat, Apr 30, 2011 at 2:54 PM, Reindl Harald wrote:
>
> Am 30.04.2011 14:04, schrieb Ferenc Kovacs:
> > Hi.
> >
> > recently I found a nice blogpost about how to properly daemonize a php
> > daemon:
> >
> http://andytson.com/blog/2010/05/daemonising-a-php-cli-script-on-a-posix-system/
> > I've n
On Sat, 30 Apr 2011 13:04:12 +0100, Ferenc Kovacs wrote:
recently I found a nice blogpost about how to properly daemonize a php
daemon:
http://andytson.com/blog/2010/05/daemonising-a-php-cli-script-on-a-posix-system/
I've noticed in this article, that you can replace/redirect the
STDIN/STDOUT/S
Am 30.04.2011 14:04, schrieb Ferenc Kovacs:
> Hi.
>
> recently I found a nice blogpost about how to properly daemonize a php
> daemon:
> http://andytson.com/blog/2010/05/daemonising-a-php-cli-script-on-a-posix-system/
> I've noticed in this article, that you can replace/redirect the
> STDIN/STDOU
On Sat, Apr 30, 2011 at 2:18 PM, Alain Williams wrote:
> On Sat, Apr 30, 2011 at 02:04:12PM +0200, Ferenc Kovacs wrote:
> > Hi.
> >
> > recently I found a nice blogpost about how to properly daemonize a php
> > daemon:
> >
> http://andytson.com/blog/2010/05/daemonising-a-php-cli-script-on-a-posix
On Sat, Apr 30, 2011 at 02:04:12PM +0200, Ferenc Kovacs wrote:
> Hi.
>
> recently I found a nice blogpost about how to properly daemonize a php
> daemon:
> http://andytson.com/blog/2010/05/daemonising-a-php-cli-script-on-a-posix-system/
> I've noticed in this article, that you can replace/redirect
Hi.
recently I found a nice blogpost about how to properly daemonize a php
daemon:
http://andytson.com/blog/2010/05/daemonising-a-php-cli-script-on-a-posix-system/
I've noticed in this article, that you can replace/redirect the
STDIN/STDOUT/STDERR from inside of your script, you have to close them
36 matches
Mail list logo
