* Theo Schlossnagle (jesus(at)omniti(dot)com) wrote:
> I'd like to be able to creatively solve this problem without modifying
> the core, but today I cannot.
I thought a hook already existed for this (there's already a module
which uses a hook to log commands done as a superuser, for example)..
Perhaps it wasn't in the right place, however.
> So... here's my first whack at solving this with some flexibility.
I was hoping to work on something similar (and have discussed it with
Magnus a few times) but with much more flexibility. Basically, have a
structure where there's a lot of meta-data available that can easily be
used to direct where a log message goes (or if it's logged at all), all
without having to actually parse the log message (which is painful..).
To be honest, I was consdiering something like what syslog-ng provides,
but PG specific, not needing regexp's (though perhaps supporting them)
and with multiple different destination types and locations.
Independent of all that, if we don't have hooks already that can be used
for this, I certainly think it makes sense to add some, even if we do
something more later.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2011-11-27 23:20:18|
|Subject: Re: hiding variable-length fields from Form_pg_* structs |
|Previous:||From: Tom Lane||Date: 2011-11-27 23:17:49|
|Subject: Re: pg_upgrade automatic testing |