I think the read-only has two meanings for the user.
(BFirst is the internal state. XID, OID or something like that.
(BIn these cases, the internal state mustn't be changed.
(BSome users will need the read-only for internal state.
(BSecond is read-only for the user data contents.
(BIn some cases, the user want to make the user data as read-only.
(BFor this purpose, the user doesn't care XID or OID, I guess.
(BSo, we can implement them in different way.
(BI think both are necessary.
(BBruce Momjian wrote:
(B> Tom Lane wrote:
(B>>Bruce Momjian <firstname.lastname@example.org> writes:
(B>>>It seems server_read_only is the same as default_transaction_read_only
(B>>>except it can't be changed.
(B>>I thought the TODO item was for a low-level read-only option, suitable
(B>>for trying to look at a corrupted database or run off a read-only volume.
(B>>This is very far from being that --- it allows temp table creation/use,
(B>>and it still eats transaction IDs so it is certainly not read-only to
(B>>xlog or clog.
(B>>I am not sure I see any use case for this implementation: it is
(B>>read-only enough to get in your way, without being read-only enough
(B>>to derive any real benefit.
(B> I am not sure I see the use case either but I developed it so everyone
(B> could look at it and decide if it is useful. When true, it is basically
(B> a unchangable default_transaction_read_only.
(BNAGAYASU Satoshi <[EMAIL PROTECTED]>
(BOpenSource Development Center,
(BNTT DATA Corp. http://www.nttdata.co.jp/
(B---------------------------(end of broadcast)---------------------------
(BTIP 6: Have you searched our list archives?