Обсуждение: Is there PHP mysql_real_escape_string for postgresql?
In php is there a postgresql version of mysql_real_escape_string() ?
On Dec 17, 2007, at 8:37 PM, dterrors@hotmail.com wrote: > In php is there a postgresql version of mysql_real_escape_string() ? You have both pg_escape_string and pg_escape_bytea available. Erik Jones Software Developer | Emma® erik@myemma.com 800.595.4401 or 615.292.5888 615.292.0777 (fax) Emma helps organizations everywhere communicate & market in style. Visit us online at http://www.myemma.com
In response to Erik Jones <erik@myemma.com>: > > On Dec 17, 2007, at 8:37 PM, dterrors@hotmail.com wrote: > > > In php is there a postgresql version of mysql_real_escape_string() ? > > You have both pg_escape_string and pg_escape_bytea available. Is there a mysql_fake_escape_string()? Should PostgreSQL have a pg_pretend_to_escape_string() that effectively does nothing? -- Bill Moran http://www.potentialtech.com
On Dec 20, 2007, at 9:46 AM, Bill Moran wrote: > In response to Erik Jones <erik@myemma.com>: > >> >> On Dec 17, 2007, at 8:37 PM, dterrors@hotmail.com wrote: >> >>> In php is there a postgresql version of mysql_real_escape_string() ? >> >> You have both pg_escape_string and pg_escape_bytea available. > > Is there a mysql_fake_escape_string()? Should PostgreSQL have a > pg_pretend_to_escape_string() that effectively does nothing? Good one :-) Erik Jones Software Developer | Emma® erik@myemma.com 800.595.4401 or 615.292.5888 615.292.0777 (fax) Emma helps organizations everywhere communicate & market in style. Visit us online at http://www.myemma.com
Bill Moran wrote: > In response to Erik Jones <erik@myemma.com>: > >> On Dec 17, 2007, at 8:37 PM, dterrors@hotmail.com wrote: >> >>> In php is there a postgresql version of mysql_real_escape_string() ? >> You have both pg_escape_string and pg_escape_bytea available. > > Is there a mysql_fake_escape_string()? Should PostgreSQL have a > pg_pretend_to_escape_string() that effectively does nothing? Ah, that's not real as in "reality", it's réal as in "royal" because the initial code submission came from Queen Sofía of Spain who knows a surprising amount about hacking in "C" but still maintains that referential integrity is best handled in the application layer. -- Richard Huxton Archonet Ltd
At 10:46a -0500 on 20 Dec 2007, Bill Moran wrote: > In response to Erik Jones <erik@myemma.com>: >>> In php is there a postgresql version of mysql_real_escape_string() ? >> You have both pg_escape_string and pg_escape_bytea available. > > Is there a mysql_fake_escape_string()? Should PostgreSQL have a > pg_pretend_to_escape_string() that effectively does nothing? Haha! Awesome! You should "count it," Bill. Serious now, who writes the code for those PHP functions? Is that a call that PHP makes to the respective database or does someone actually continually keep the PHP code "up-to-date"? Second question: why is there not more emphasis on using prepared statements? I was taught at $SCHOOL that prepared statements, especially for anything involving unknown user input, is the Right Way. Am I missing something or is the lack of use of these just a noob factor? Thanks, Kevin
Kevin Hunter wrote: >>In response to Erik Jones <erik@myemma.com>: >> >>>>In php is there a postgresql version of mysql_real_escape_string() ? >>> > > Serious now, who writes the code for those PHP functions? Is that a > call that PHP makes to the respective database or does someone actually > continually keep the PHP code "up-to-date"? Well, the credits for the pgsql parts of PHP 5.14 are: Jouni Ahto, Zeev Suraski, Yasuo Ohgaki, and Chris Kings-Lynne and it uses libpq. As far as keeping it up-to-date, i suppose that the maintainers of the various modules do so with each PHP release. The reason for the oddly-named mysql_real_escape_string is that an older function, mysql_escape_string() has been deprecated. I wonder, though, why the new functionality couldn't have simply been rolled into that. After all, the only differece, AFAIK, is that the newer function takes the connection handler as the [optional] second param so as to use the proper character set. So it doesn't seem that it would have been a problem for legacy code. Perhaps there's a good reason, though i can't think of any good reason for the silly new name. But i'm not surprised, given the dearth of standards in PHP (like dicking around with how params are passed to any given function--does the needle come first, or the haystack?). > Second question: why is there not more emphasis on using prepared > statements? I was taught at $SCHOOL that prepared statements, > especially for anything involving unknown user input, is the Right Way. > Am I missing something or is the lack of use of these just a noob factor? I'm late in arriving at this thread but that'd be my advice, too. I recommend the PEAR MDB2 package. In regard to your last question, i think a big reason is that, until fairly recently, prepared statements weren't possible without some sort of wrapper (eg. MDB2) so a lot of people stuck with shared hosting just don't have access to them. There are pg_prepare() and pg_execute() now (for PHP > 5.1) but i haven't needed to use them. Actually, now i think of it, it is possible to include PEAR packages locally (ie. from within a particular website as opposed to using an "installed" setup) but it could be a bit of a dependency pain for certain packages. brian
On Dec 17, 2007 9:37 PM, <dterrors@hotmail.com> wrote: > In php is there a postgresql version of mysql_real_escape_string() ? There is (mentioned upthread), but if you are writing C vs. libpq you may want to take a look a the parameterized interface. It's a little raw but parameterized queries do not have to escaped. see: PQexecParams merlin