Re: Protection from SQL injection - Mailing list pgsql-hackers

From Chris Browne
Subject Re: Protection from SQL injection
Date
Msg-id 60skx01nsm.fsf@dba2.int.libertyrms.com
Whole thread Raw
In response to Re: Protection from SQL injection  (Darren Reed <darrenr+postgres@fastmail.net>)
Responses Re: Protection from SQL injection  (Andrew Sullivan <ajs@commandprompt.com>)
List pgsql-hackers
alvherre@commandprompt.com (Alvaro Herrera) writes:
> Darren Reed wrote:
>
>> Because interacting with the database is always through an action
>> that you do and if you're being half way intelligent about it, you
>> are always checking that each action succeeded before going on to
>> the next.
>
> Hmm, it won't be pretty for the drivers that do PQexec("COMMIT; BEGIN").
> The driver will think that it's in a transaction when in fact the second
> command in the string has been ignored, and so it's not ...

We have worked pretty hard around here to expunge use of drivers that
do this sort of thing.  (Cough, cough, "dbrow"...)

Recent versions of PostgreSQL don't suffer too badly, but back in the
7.2/7.4 days, we had applications that left transactions open "<IDLE>
in transaction" for days at a time (if a user quit using the web app
without expressly logging out), with _atrocious_ results.

Andrew Sullivan recently had some choice words about the merits of
ENUM; I think the same applies to drivers that do
PQexec("COMMIT;BEGIN")...
-- 
output = ("cbbrowne" "@" "linuxfinances.info")
http://www3.sympatico.ca/cbbrowne/advocacy.html
:FATAL ERROR -- ILLEGAL ERROR


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Sigh ...
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] GUC parameter cursors_tuple_fraction