Bruce Momjian <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> I thought that this was rejected thouroughly by Tom some months ago.  He 
>> argued pretty strongly that READ ONLY transactions were *not* a security 
>> feature and that trying to make them one would work very poorly.

> I remember something like that, but I thought the patch was the result
> of that discussion.  Tom?

Hm, I can't find anything in the archives in which I said that.  I did
argue that using GUC to control a security feature would be a mistake:
and after watching Bruce struggle with trying to make logging-related
GUC settings secure, I think my point is pretty much proved ;-).
I don't want to see more cruft like that added to the GUC logic.

Another thing to think about is that the semantics of START TRANSACTION
READ ONLY are constrained by the SQL standard, and they are not exactly
"read only" in the traditional sense (eg, you can still create and use
temp tables).  If we go down this path, I would be unsurprised to run
into a showstopper conflict between what's needed for reasonably
"secure" behavior and what the spec dictates.  It would be less risky
to use some other approach, if we are really interested in creating
read-only users.

So I'm still of the opinion I gave in the above-mentioned thread, that
I'd rather make "read only user" be a concept driven by a flag in the
user's pg_shadow entry.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to