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: http://archives.postgresql.org/pgsql-patches/2003-07/msg00198.php 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
