Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63933
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
Sender: patrick.allaert@gmail.com
In-Reply-To: <50A67B09.4060808@lerdorf.com>
References: <CACwt+JeJ-H0e+MB-d7skTejoksCsHShB7_U8z1ke7EYWZ=-pWw@mail.gmail.com>
	<50A6691E.2080102@lerdorf.com>
	<CACwt+JcDLiGyq0jE6BZuxUkXJjU7X3WaOnysJWJ9yyccvtUSWg@mail.gmail.com>
	<50A67B09.4060808@lerdorf.com>
Date: Fri, 16 Nov 2012 18:50:22 +0100
Message-ID: <CACwt+JdVw3ww_rz+Tnc-x_kEU-3wd_V7mL2S_8Qw2=15Bi6oYg@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Adam Harvey <aharvey@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)
From: patrickallaert@php.net (Patrick ALLAERT)

2012/11/16 Rasmus Lerdorf <rasmus@lerdorf.com>:
> On 11/16/2012 09:32 AM, Patrick ALLAERT wrote:
>> 2012/11/16 Rasmus Lerdorf <rasmus@lerdorf.com>:
>>> On 11/16/2012 02:18 AM, Patrick ALLAERT wrote:
>>>> In eZ Publish CMS, we have recently removed [1] support for the mysql
>>>> handler in favour of the mysqli one and as such, we have no more
>>>> mysql_*() functions calls except for the above use case where we rely
>>>> on mysql_escape().
>>>
>>> I suppose you mean mysql_real_escape_string() here. There is no
>>> mysql_escape() function and mysql_escape_string() is already marked as
>>> deprecated as of 5.3.
>>>
>>> -Rasmus
>>
>> Sorry, I meant mysql_escape_string().
>> I missed the fact it was already deprecated and as such, we have an
>> issue here in our code base since nor mysql_real_escape_string() nor
>> mysqli_real_escape_string() fits our use case as we are using it when
>> we have to generate an SQL file with queries to be executed on another
>> box. Not having access to a database prevents us to have a link which
>> is required by those functions.
>
> But without a link you don't know which charset the db is in and
> therefore you can't reliably escape a query. In your case you can do a
> custom escape thing based on the fact that you might know the
> destination charset, but PHP on its own can't.

We are defining the charset used at the beginning of the generated
file and wish it could be possible to pass the charset rather than a
link which is what is really needed.
Looks like a valid feature request to me. Would make sense only for
the procedural call of course. The first argument could then be a
resource or a string.