Search Postgresql Archives

Re: Is there PHP mysql_real_escape_string for postgresql?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Hunter wrote:
In response to Erik Jones <erik@xxxxxxxxxx>:

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux