Re: [GENERAL] More PHP DB abstraction layer stuff - Mailing list pgsql-interfaces

From Lincoln Yeoh
Subject Re: [GENERAL] More PHP DB abstraction layer stuff
Date
Msg-id 5.1.0.14.1.20030125052323.02835920@mbox.jaring.my
Whole thread Raw
In response to More PHP DB abstraction layer stuff  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
List pgsql-interfaces
At 02:44 AM 1/25/03 +1030, Justin Clift wrote:

>If it's any help, and approach that I feel is safe is to use the PHP
>functions rawurlencode() on all data as soon as it hits the page, then use
>that encoded data everywhere in the PHP code (including for storage in the
>database), and use rawurldecode() if/when it needs to be spat out to a browser.
>
>The only real disadvantage is that column widths for data storage need to
>be wider, but for databases without huge resource requirements it's not
>real noticeable, and the data is pretty safe in encoded form.

I prefer an approach where filters are kept separate. You have different
input filters so that your program can deal with each different input properly.

I doubt your program can do much with rawurlencoded cgi parameters without
decoding them.

You then have different output filters so the different programs (and
contexts) your program sends output to can deal with the output.

Using the same filter for everything seems to be a popular habit in the PHP
community. Magic quotes etc. That sort of thing tends to produce the
"backslash everywhere" syndrome, corrupting data needlessly. Personally it
gives me a bad impression of the thought that went into the design of many
PHP "features".

Cheerio,
Link.


pgsql-interfaces by date:

Previous
From: Gerhard Häring
Date:
Subject: Re: Python DB-API problem with PostgresSQL pgdb.
Next
From: Greg Stark
Date:
Subject: Re: [GENERAL] More PHP DB abstraction layer stuff