Re: pg_escape_literal(), pg_escape_identifier() patch

From: Date: Tue, 22 Nov 2011 11:35:41 +0000
Subject: Re: pg_escape_literal(), pg_escape_identifier() patch
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-56466@lists.php.net to get a copy of this message
Amazing! I was in big troubles with multibyte escaping a couple years ago. Nowadays, after a big ship of encoding problems (not only with db, but navigator encoding, proxy caching and so on), I've ported everything to UTF-8 (this included rewrite a 8 years old application). I guess this is a good implementation, considering that many people still use old PostgreSQL versions. About pg_escape_identifier, fixes this an old problem when we use some reserved column names, like "login"? On Mon, Nov 21, 2011 at 8:41 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi all, > > I've posted pgsql patch that adds > pg_escape_literal()/pg_escape_identifier() which escapes SQL literal > and idetifier. (i.e. table names, filed names, etc) > > https://gist.github.com/1381181 > > When I post a patch while ago, someone mentioned about that pgsql > module own escape implementation may not be needed. I'm OK with both > with/without pgsql own escape implementation. I ported escaped > function that handles multibyte string correctly, in case of libpq > does not have it. i.e. PostgreSQL 8.4 or less. As far as I know, older > PostgreSQL (at least 8.0 >) handles literal/identifier escape > correctly. > > It seems trunk is open for new feature. I'll commit the patch as is if > there is no objection. > > Any comments? > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Atenciosamente, Rafael Kassner

« previous php.internals (#56466) next »