On Thu, Aug 14, 2014 at 7:19 PM, Stephen Frost <
sfrost@snowman.net> wrote:
> * Amit Kapila (
amit.kapila16@gmail.com) wrote:
> > On Thu, Aug 14, 2014 at 5:56 AM, Stephen Frost <
sfrost@snowman.net> wrote:
> > > Regarding this, I'm generally in the camp that says to just include it
> > > in 'all' and be done with it- for now.
> >
> > Okay, but tomorrow if someone wants to implement a patch to log
> > statements executed through SPI (statements inside functions), then
> > what will be your suggestion, does those also can be allowed to log
> > with 'all' option or you would like to suggest him to wait for a proper
> > auditing system?
>
> No, I'd suggest having a different option for it as that would be a huge
> change for people who are already doing 'all', potentially.
Not only that, I think another important reason is that those represent
separate set of functionality and some users could be interested to
log those statements alone or along with other set of commands.
> Adding the
> replication commands is extremely unlikely to cause individuals who are
> already logging 'all' any problems, as far as I can tell.
As 'all' is superset for all commands, so anyway it would have been
logged under 'all', the point is that whether replication commands
can be considered to have a separate log level parameter. To me, it
appears that it deserves a separate log level parameter even though
today number of commands which fall under this category are less,
however it can increase tomorrow. Also if tomorrow there is a consensus
on how to extend log_statement parameter, it is quite likely that
someone will come up with a patch to consider replication commands
as separate log level.
I think ideally it would have been better if we could have logged
replication commands under separate log_level, but as still there
is no consensus on extending log_statement and nobody is even
willing to pursue, it seems okay to go ahead and log these under
'all' level.
