On Mon, Aug 20, 2012 at 7:17 PM, David Johnston <pol...@yahoo.com> wrote: > Ideally the decision of whether to do so could be a client decision. Not > storing intra-transaction changes is easier than storing all changes.
Not really. If you don't care about suppressing intra-transaction changes, you can essentially just have a trigger that fires on every update and adds information to the side table. If you do care about suppressing them, you have to do something more complicated. Or so it seems to me. > I see the "user" element as having two components: > > "Client" - what device/channel/"user" was used to connect to the database - > PostgreSQL Role > "User" - relative to that "client" which actual "user" performed the action > - Application Specified > > A PostgreSQL role would correspond to "client" whereas the application would > be allowed to have full control of what "User" value is stored. > > This gets a little complicated with respect to "SET ROLE" but gets close to > the truth. The idea is that you look at the "client" to determine the > "namespace" over which the "user" is defined and identified. > > So, a better way to phrase the position is that: > > "You cannot allow the application to choose what is stored to identify > itself (client)" - i.e., its credentials identify who it is and those are > stored without consulting the application I don't think we can violate the general principle that the database super-user or table owner can do whatever they want. If one of those folks wants to falsify their history, are we really going to tell them "no"? To me that has "I'm sorry, Dave, I can't do that" written all over it, and I think we'll get about the same reaction that Hal did. Now, if user A is inserting into user B's table, and is not the super-user, then, of course, we can and should ensure that no falsification is possible. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
