RE: [PHP-DEV] Re: [PHP] PDO prepared statements and LIKE escaping
If you are supporting international users, then you also have to worry about the full-width versions of the operators (%, *, etc.) Whether they are treated the same as half-width characters depends on the database. Oracle for example treats them as equivalent. -Original Message- From: Lester Caine [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2008 12:35 AM To: PHP internals Subject: [PHP-DEV] Re: [PHP] PDO prepared statements and LIKE escaping Larry Garfield wrote: > I'm building a multi-database system, although my main targets are > MySQL, Postgres, and SQLite. > > How would those handle something like "a string that ends in 100%"? Personally this is one of the reasons that PDO has never attracted me. Providing the tools to flatten some of the differences between *SQL* variations is just as important as flattening the name differences in functions. My own use of LIKE tends to process the string and then add the wrapping %% when passing it to the param array, but do all databases HANDLE 'escaped %' in the LIKE data? Firebird allows a escape character but you need to include it in the SQL LIKE '%100#%%' ESCAPE '#' But I think MySQL actually uses \% to achieve the same thing - and the ESCAPE '\' is then optional? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Algorithm Optimizations - string search
Ok, well then the code needs to use internationalized functions for string upper and lower. Operating on the first character of the string without surrounding context is incorrect. Operating on the string without locale is also incorrect. The string operations should use ICU. Also, ICU uses boyer-moore I believe. (Or it did last time I looked.) Some other issues as well, but I will have to look at the code. I wasn't thinking utf-16, so you might also look at surrogates. Are there guidelines for php coding, and proper support for utf-16? > -Original Message- > From: Johannes Schlüter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 11, 2008 5:32 AM > To: Texin, Tex > Cc: Scott MacVicar; Nuno Lopes; internals@lists.php.net; > Michal Dziemianko > Subject: RE: [PHP-DEV] Algorithm Optimizations - string search > > Hi, > > On Wed, 2008-06-11 at 01:01 -0700, Texin, Tex wrote: > > When I looked at the code, I assumed that it wasn't intended for > > international use I'll have to go back and look to give you > details, but it doesn't work for international use or unicode. > > It would be ok for 8859-1. > > That's the default case in PHP < 6, in current PHP versions > all string operations use on "binary" strings, so all > references to offset work on byte not character base. That's > one of the main reasons for PHP 6. > > johannes > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Algorithm Optimizations - string search
When I looked at the code, I assumed that it wasn't intended for international
use
I'll have to go back and look to give you details, but it doesn't work for
international use or unicode.
It would be ok for 8859-1.
> -Original Message-
> From: Scott MacVicar [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 09, 2008 6:58 AM
> To: Nuno Lopes
> Cc: internals@lists.php.net; Michal Dziemianko
> Subject: Re: [PHP-DEV] Algorithm Optimizations - string search
>
> There is rabin-karp too but its worse case is O(nm) so that
> might not be ideal, perhaps we should try to compare all of them.
>
> Scott
>
> Nuno Lopes wrote:
> > Hi,
> >
> > So some comments:
> > - you have some problems with the indentation. We only use tabs, so
> > please stick to that. Also, there are some lines that are
> not indented
> > correctly
> > - Have you considered the Boyer-Moore algorithm? I think
> it's a little
> > faster than KMP (take a look at e.g.
> > http://www.cs.utexas.edu/users/moore/best-ideas/string-searching/)
> > - please remove the //TUTAJ SKONCZYLEM comment
> > - revert this change (as well as a few other that are similar):
> >- for (r_end = r + Z_STRLEN_P(return_value) - 1; r <
> r_end; ) {
> > + for ( r_end = r + Z_STRLEN_P( return_value ) - 1; r
> < r_end;
> > ){ (we like small diffs, not long diffs with changes that
> also break
> > our coding standards. e.g. we don't use space after the '(' char.
> > Philip wrote a nice article about diffs at
> > http://wiki.php.net/doc/articles/whitespace)
> > - in strrpos_reverse_kmp() I think you allocate 4 bytes
> less that you
> > want
> > - I think you've too many comments.. We don't need 1
> comment per line
> > :)
> >
> > After fixing all these points and after running the test suite (with
> > valgrind) and make sure there are no regressions, I think it's safe
> > for you to commit. Still, I would like to see some
> performance figures
> > comparing the KMP and the Boyer-Moore (or point me some
> papers about
> > the subject).
> >
> > Thanks for your work and good luck for the rest of the SoC
> project :)
> >
> > Nuno
> >
> >
> > - Original Message - From: "Michal Dziemianko"
> > <[EMAIL PROTECTED]>
> > To:
> > Sent: Monday, June 09, 2008 12:39 PM
> > Subject: [PHP-DEV] Algorithm Optimizations - string search
> >
> >
> >> Hello,
> >> Here: http://212.85.117.53/DIFF.txt is small patch that
> will speed
> >> up following functions:
> >> strpos,
> >> stripos,
> >> strrpos
> >> strripos,
> >> and probably some others (all that use zend_memnstr/php_memnstr
> >> function)
> >>
> >> The speedup of zend_memnstr is about 8% on average (about
> 30% in case
> >> of artificial strings).
> >> Functions strrpos and strripos are about 25% faster on average.
> >>
> >> The only drawback - it needs some additional space (size
> of the needle).
> >>
> >> All functions pass all the tests.
> >>
> >> If it looks fine than I will apply for cvs account.
> >>
> >> Cheers,
> >> Michal
> >
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List To
> unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
