Sean Chittenden wrote:
> > > > Um, why not make it an actual full blown security feature by
> > > > applying the following patch? This gives PostgreSQL real read
> > > > only transactions that users can't escape from. Notes about the
> > > > patch:
> > >
> > > Way nifty.
> > >
> > > I vote in favor of this patch (suitably documented & debugged) for 7.5.
> >
> > Heh, there ain't much to debug: it's pretty straight forward. I ran
> > all the use cases/syntaxes I could think of and they worked as
> > expected. It's a pretty chump little ditty that I originally wrote
> > for the sake of the 7.4 PR, but it's proving to be quite useful here
> > in my tree... though I like the name "jail_read_only_transactions"
> > more... patch updated for new name.
>
> Err.. and attached. -sc
I assume this patch is to control this way of breaking out of a
read-only transaction:
test=> START TRANSACTION READ ONLY;
START TRANSACTION
test=> CREATE TABLE x(y INT);
ERROR: transaction IS read-only
test=> COMMIT;
COMMIT
test=> START TRANSACTION READ ONLY;
START TRANSACTION
test=> SET transaction_read_only = FALSE;
SET
test=> CREATE TABLE x (y INT);
CREATE TABLE
test=> COMMIT;
COMMIT
This seems like a valuable feature, as others have mentioned. However,
should it also prevent changes to default_transaction_read_only?
What is the use case for this functionality?
Seems someone could easily break out of this by doing:
test=> START TRANSACTION READ ONLY;
START TRANSACTION
test=> COMMIT;
COMMIT
test=> START TRANSACTION;
START TRANSACTION
test=> CREATE TABLE x (y INT);
CREATE TABLE
This shows that default_transaction_read_only probably has to be
restricted too by the same variable.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
