Re: [GENERAL] Re: [HACKERS] TRANSACTIONS

At 02:16 PM 24-02-2000 -0500, Karl DeBisschop wrote:
>
>To summarize, I stated that the following does not work with
>postgresql:
>
>> $dbh->{AutoCommit} = 0;
>> $dbh->do("CREATE TABLE tmp (a int unique,b int)");
>>         $rtv = $dbh->do("INSERT INTO tmp VALUES ($1,$2)");
>>         if ($rtv) {$dbh->do("UPDATE tmp SET b=$2 where a=$1")};
>> $dbh->commit;
>> $dbh->disconnect;
>
>It's not that eval's error trapping is blown out - it's that the
>transaction defined by the AutoCommit cannot complete because a part
>of it cannot complete -- that's what atomicity means.

Maybe I don't understand the situation. But it doesn't seem to be a big
problem.

With postgres you have ensure that your application filters the data
properly before sticking it into the database. Then if the insert fails,
it's probably a serious database problem and in that case it's best that
the whole transaction is aborted anyway.

It indeed is a problem if the database engine is expected to parse the
data. For example - if you send in a date value, and the database engine
chokes on it. With the nonpostgresql behaviour you can still insert a NULL
instead for "Bad date/ Unknown date".

But from the security point of view it is best to reduce the amount of
parsing done by the database engine. Make sure the app sanitises and
massages everything so that the database has no problems with the data. It
can be a pain sometimes to figure out what the database can take (which is
why I've been asking for the limits for Postgresql fields and such- so the
app can keep everything within bounds or grumble to the user/vandal). Once
everything is set up nicely, if the database grumbles then the app screwed
up somehow (the vandal got through) and it's best to rollback everything
(we're lucky if the database just grumbled).

Cheerio,

Link.