On 10 January 2017 at 14:31, Fabien COELHO <coelho@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