On Mon, Aug 20, 2012 at 7:17 PM, David Johnston <polobo@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