* Peter Eisentraut (pete...@gmx.net) wrote: > On 5/4/15 3:00 PM, Stephen Frost wrote: > > One particular advantage of having the extension is that having it > > doesn't impact existing users of the in-core logging system. I don't > > recall any specific proposals for improving the in-core logging system > > to add the capabilities for session logging that the extension > > provides, but it seems likely to require changes to at least the CSV > > format, new log_line_prefix escape codes (which we're using quite a > > few of already...), new GUCs, and potentially behavior changes to make > > it work. As I say above, I'm happy to have those discussions (and > > I've been party to them quite a few times in the past...), > > Well yeah, from my perspective, the reason not much has happened in the > area of logging is that you and Magnus have repeatedly said you were > planning some things.
If that was holding anyone back from working on it, then I'm truely
sorry. I would encourage anyone interesting in any particular feature
to speak up and ask what the status is and if others are working on
something, especially if they have time to spend advancing it. I was
certainly quite happy when Abhijit posted the initial version of this
nearly a year ago as it showed that there were individuals able to spend
substantial time on it, as well as a use-case which would be solved
through such an extension.
I don't wish to lay claim to any particular feature nor to make any
guarantees, but I will say that I'm happy to have moved into a position
in the past year where I can devote a great deal more in time and
resources towards PostgreSQL than I've ever been able to in the past.
> The reasons given above against changing logging just as easily apply to
> auditing.
I don't follow this logic. The concerns raised above are about changing
our in-core logging. We haven't got in-core auditing and so I don't see
how they apply to it.
> This implementation is only a starting point. We don't know
> whether it will fulfill anyone's requirements. The requirements for
> logging are "it feels good enough for an admin". The requirements for
> auditing are "it satisfies this checklist". We need to be prepared to
> aggressively evolve this as we gather more information about
> requirements. Otherwise this will become something like contrib/isn,
> where we know it doesn't satisfy real-world uses anymore, but we're
> afraid to touch it because someone might be using it and we don't have
> the domain knowledge to tell them to stop.
I agree that this is a starting point. From the discussions which I've
had with PostgreSQL users (both our clients and others), this does
fulfill a set of requirements for them. That isn't to say that it's a
complete and total solution, nor that we will stop here (we certainly
won't!), but I'm confident it *is* solving a real use-case for our
users. I don't mean to speak for them, but my understanding is that the
work which was done by Abhijit and 2ndQ was sponsored by an EU grant
which had a specific set of requirements which this is intended to
satisfy.
Further, we are absolutely prepared to aggressively evolve this as we
learn and understand how it's being used out in the field- but I don't
believe we're ever going to really understand that until we put
something out there.
Thanks!
Stephen
signature.asc
Description: Digital signature
