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
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
Hi,
Thanks for the comments.
2011/11/22 Rafael Kassner kassner@gmail.com:
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 danielc@analysisandsolutions.com:
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
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
Hi Pierre,
2011/11/23 Pierre Joye pierre.php@gmail.com:
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
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
Hi Stats,
2011/11/24 Stas Malyshev smalyshev@sugarcrm.com:
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?
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
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
2011/11/25 Yasuo Ohgaki yohgaki@ohgaki.net:
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
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