Re: pg_escape_literal(), pg_escape_identifier() patch
| From: | Rafael Kassner | 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