From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Satoshi Nagayasu <nagayasus(at)nttdata(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] read-only database |
Date: | 2005-05-10 03:03:51 |
Message-ID: | 3971.1115694231@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Having removed our security for not allowing override of things like
> log_statement, it seems we need a more general capability for
> controlling how something can be set that no one can change.
The initial implementation was definitely pretty broken, but I agree
we should try again.
I think that transaction_read_only and default_transaction_read_only
are a special case: they embody our implementation of SQL-spec-mandated
features (SET TRANSACTION READ ONLY and friends), and so any messing
about with them has to surmount the objection that it'll be breaking
spec-mandated behavior. But the other things we wanted this for in
the past, such as logging control, were outside the scope of the spec
AFAIR.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Satoshi Nagayasu | 2005-05-10 03:18:10 | Re: [HACKERS] read-only database |
Previous Message | Bruce Momjian | 2005-05-10 02:50:34 | Re: [HACKERS] read-only database |
From | Date | Subject | |
---|---|---|---|
Next Message | Satoshi Nagayasu | 2005-05-10 03:18:10 | Re: [HACKERS] read-only database |
Previous Message | Bruce Momjian | 2005-05-10 02:50:34 | Re: [HACKERS] read-only database |