On Thu, Aug 14, 2014 at 7:19 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Amit Kapila (amit.kapil...@gmail.com) wrote: > > On Thu, Aug 14, 2014 at 5:56 AM, Stephen Frost <sfr...@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. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
