On 10 January 2017 at 14:31, Fabien COELHO <coe...@cri.ensmp.fr> wrote:
> I have submitted a proof of this fact in the form of a counter example which > (1) (pseudo) implements the use-case by logging into an audit table the fact > a user accesses the secure level (2) shows that the status of a non > transactional session variable used for keeping this status is wrong for the > use case in some cases (it says that all is well while appending to the > audit table failed). You've been assuming everyone else cares about auditing such access into a table. Personally I tend to agree with you that it's useful enough to justify transactional vars. But you're fixated on the idea that without that use case satisfied the rest is useless, and that's simply not the case. Transactional vars are only needed if you make _write_ changes to the DB that must be committed atomically with the var change. If you're only doing (maybe expensive) lookups, it doesn't matter. > I feel entitled to point out to other people that their belief that a > feature as described provides a correct solution to a particular use case is > wrong, if it is factually the case. If they persist in this belief despite > the submitted proof, I can only be sad about it, because if pg provides a > feature for a security-relared use case which does not work correctly it is > just shooting one's foot. Again ... I think you've assumed everyone else is talking about the same security-related case you are. I haven't seen Pavel talking about access audit logging. If he has been, then my mistake and you're quite correct. But my reading is that you've been _assuming_ that. > I do not like Pavel's feature, this is a subjective opinion. This feature > does not provide a correct solution for the use case, this is an objective > fact. For _your_ use case. > The presented feature does not have a real use case, this is too bad. No, it just doesn't match your idea of what the use case is. It does have other uses that are perfectly valid. Look up access rights, set var. It's fine. Now, I think we might as well do it transactionally, but it's not some kind of absolute requirement; if you're not transactional, it just means you can't do reliable audit logging of access into tables. Of course, we can't do that already for anything else. It's kind of like someone coming to you and saying they want to add an engine to their glider, and you explaining that it's totally useless to add an engine unless it can also function as a submarine. Um, that's nice, but not what they asked for. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
