Re: SQL safe input?

Поиск
Список
Период
Сортировка
От
Тема Re: SQL safe input?
Дата
Msg-id 20050827232251.62145.qmail@web33309.mail.mud.yahoo.com
обсуждение исходный текст
Ответ на Re: SQL safe input?  (Bruno Wolff III <bruno@wolff.to>)
Ответы Re: SQL safe input?  (Bruno Wolff III <bruno@wolff.to>)
Список pgsql-novice

--- Bruno Wolff III <bruno@wolff.to> wrote:

> On Fri, Aug 26, 2005 at 15:40:02 -0700,
>   operationsengineer1@yahoo.com wrote:
> > > IMO the best way to do this is to use bind
> > > parameters to pass user input
> > > to queries. Then you don't need to escape
> anything.
> > > You might still check
> > > for very long strings.
> >
> > this got me thinking...  is this what you are
> talking
> > about (i use ADOdb)?
> >
> > $db->Execute("INSERT INTO t_customer
> (customer_name,
> > customer_entry_date) VALUES (?,?)",
> > array($customer_name, $db->DBDate(time())));
> >
> > $customer_name is the validated input from the
> user
> > with no escaping of any kind.  is this ok?
> >
> > this query works just dandy.  does it mean i can
> start
> > sleeping at night?  -lol-
>
> Yes this is the idea. Bad data for the values can't
> execute unexpected SQL
> commands; it can only cause the query to fail.

nice!  pretty painless, too.  do you mind spending a
minute explaining the mechanics?  obviously, the
format does a little more than just input the values,
otherwise it would be just like the other format.

if bad data is submitted, is there something going on
"behind the scenes" to scrub the bad data and cause
the query to fail instead of run with the bad data?
how does the the system know the data is bad data?

this is new to me, but very interesting.

tia...

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

В списке pgsql-novice по дате отправления:

Предыдущее
От: Dane Ensign
Дата:
Сообщение: pgdata, pg_ctl wont start
Следующее
От: Bruno Wolff III
Дата:
Сообщение: Re: SQL safe input?