# pg_escape_literal(), pg_escape_identifier() patch - Thread: https://externals.io/message/56464 - Original archive: https://news-web.php.net/php.internals/56464 - Started by Yasuo Ohgaki on 2011-11-21T22:41:29+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #56464 — Yasuo Ohgaki — 2011-11-21T22:41:29+00:00 URL: https://externals.io/message/56464#56464 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 --- ## #56466 — Rafael Kassner — 2011-11-22T11:35:41+00:00 URL: https://externals.io/message/56464#56466 · In reply to: #56464 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"? > 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 > > -- > > > > -- Atenciosamente, Rafael Kassner --- ## #56467 — Daniel Convissor — 2011-11-22T18:51:17+00:00 URL: https://externals.io/message/56464#56467 · In reply to: #56464 Hi Yasuo: > I've posted pgsql patch that adds > pg_escape_literal()/pg_escape_identifier() pg_escape_identifier() sounds good. Regarding pg_escape_literal(), which implements PQescapeLiteral, it is very similar to PHP's pg_esacpe_string(), implementing PQescapeStringConn. What is the benefit of adding this new function? (For those wanting more info, see: http://developer.postgresql.org/pgdocs/postgres/libpq-exec.html ) Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #56468 — Yasuo Ohgaki — 2011-11-22T21:42:25+00:00 URL: https://externals.io/message/56464#56468 · In reply to: #56466 Hi, Thanks for the comments. 2011/11/22 Rafael Kassner : > 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. I think so, too. Database server's (and it's code) life is very long. > About pg_escape_identifier, fixes this an old problem when we use some> reserved column names, like "login"? Any words(valid chars) can be used with pg_escape_identifier() 2011/11/23 Daniel Convissor : > Regarding pg_escape_literal(), which implements PQescapeLiteral, it is > very similar to PHP's pg_esacpe_string(), implementing > PQescapeStringConn. What is the benefit of adding this new function? pg_escape_literal() does the basically the same thing as pg_escape_string(), except it does more strict escaping (e.g. E'escaped string') and it adds quotes around string automatically. We can think of it as fool safe escape function. Following link is the example code. I tested with PostgreSQL 8.4 and it's libpq. https://gist.github.com/1387033 I think these functions are very useful for securing PHP applications using PostgreSQL. Especially, applications that needs to use DDL. Is there any objections or comments committing it to trunk? If not, I'll commit it to trunk. It's nice to have feature for PHP 5.4. It's purely an addition to pgsql module. Therefore, it has no side effect for existing feature. 5.4.0 is in RC, but it may be ok for PHP 5.4.1, I guess. -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #56499 — Pierre Joye — 2011-11-23T11:55:31+00:00 URL: https://externals.io/message/56464#56499 · In reply to: #56468 hi, > It's nice to have feature for PHP 5.4. It's purely an addition to > pgsql module. Therefore, it has no side effect for existing feature. > 5.4.0 is in RC, but it may be ok for PHP 5.4.1, I guess. A quick note about that, PHP next is much more the way. Please see the release RFC for the explanations. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #56500 — Yasuo Ohgaki — 2011-11-23T13:47:33+00:00 URL: https://externals.io/message/56464#56500 · In reply to: #56499 Hi Pierre, 2011/11/23 Pierre Joye : > A quick note about that, PHP next is much more the way. Please see the > release RFC for the explanations. Thank you for the pointer. I should better to try add this escape features for 5.4.0. Stats, I think these new escape functions are very useful to PostgreSQL users, and it does not have any side effect to existing features. These escape functions are not mandatory, but these functions increase usability of PHP and pgsql module. Do you think it is ok to merge the patch to 5.4 branch? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #56528 — Stas Malyshev — 2011-11-23T19:36:48+00:00 URL: https://externals.io/message/56464#56528 · In reply to: #56500 Hi! > These escape functions are not mandatory, but these functions increase > usability of PHP and pgsql module. > > Do you think it is ok to merge the patch to 5.4 branch? Unless there's a very compelling reason for that (i.e., security implications, missing support for a widely used part of existing functionality, etc.) I would prefer to wait till 5.4.1 with any additions. So the question is does it have such compelling reason? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #56533 — Yasuo Ohgaki — 2011-11-23T19:47:37+00:00 URL: https://externals.io/message/56464#56533 · In reply to: #56528 Hi Stats, 2011/11/24 Stas Malyshev : > Hi! > > > […] > > Unless there's a very compelling reason for that (i.e., security > implications, missing support for a widely used part of existing > functionality, etc.) I would prefer to wait till 5.4.1 with any additions. > So the question is does it have such compelling reason? These are optional features. It would be handy for some people. 5.4 is in RC, so holding it to next release sounds reasonable. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #56606 — Yasuo Ohgaki — 2011-11-25T02:22:32+00:00 URL: https://externals.io/message/56464#56606 · In reply to: #56533 Hi all, I've just committed the patch to trunk. I'll update NEWS file and docs. If anyone notice problem, please let me know. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #56613 — Yasuo Ohgaki — 2011-11-25T04:28:47+00:00 URL: https://externals.io/message/56464#56613 · In reply to: #56606 2011/11/25 Yasuo Ohgaki : > Hi all, > > I've just committed the patch to trunk. > I'll update NEWS file and docs. > If anyone notice problem, please let me know. NEWS and docs are added. I didn't edit docs for a long time. Current doc system is excellent! -- Yasuo Ohgaki yohgaki@ohgaki.net