* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > It might be possible to do and answer that specific question- but what > > about the obvious next question: which role was this command run with? > > iow, if I log dml, how do I know what the role was when the dml > > statement was run? ie- why was this command allowed? > > I'm less than excited about that argument because it's after the fact > --- if you needed to know the information, you probably didn't have > log_line_prefix set correctly, even assuming you had adequate logging > otherwise. And logging an OID just seems too ugly to live.
Erm, really? Ok, fine, maybe you didn't have log_line_prefix set
correctly the first time you needed the information, but after you
discover that you *don't know*, you're going to be looking for an option
to let you get that information for the future. I would also suggest
that more experienced admins are going to have a default log_line_prefix
that they install on new systems they set up (I know I do...), and I'd
be suprised if knowing the role that a command is actually run as wasn't
popular among that set.
I don't like logging an OID either.
> Another little problem with the quick and dirty solution is that stuff
> that's important enough to warrant a log_line_prefix escape is generally
> thought to be important enough to warrant inclusion in CSV logs. That
> would imply adding a column and taking the resultant compatibility hit.
I'd be more than happy to add support for this to the CSV logs. I agree
that it'd make sense to do. I think we need to solve the bigger problem
of OID vs. rolename vs. lookups from elog first though.
Thanks,
Stephen
signature.asc
Description: Digital signature
