On Fri, Jun 20, 2014 at 9:48 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Fujii Masao <masao.fu...@gmail.com> writes: >> OK, I've just implemented the patch (attached) which does this, i.e., >> redefines >> log_statement as a list. Thanks to the patch, log_statement can be set >> to "none", >> "ddl", "mod", "dml", "all", and any combinations of them. The meanings of >> "none", "ddl", "mod" and "all" are the same as they are now. New setting >> value >> "dml" loggs both data modification statements like INSERT and query access >> statements like SELECT and COPY TO. > > I still don't like this one bit. It's turning log_statement from a > reasonably clean design into a complete mess, which will be made even > worse after you add replication control to it.
Well, I don't object to having a separate GUC for replication command logging if people prefer that design. But let's not have any delusions of adequacy about log_statement. I've had more than one conversation with customers about that particular parameter, all of which involved the customer being unhappy that there were only four choices and they couldn't log the stuff that they cared about without logging a lot of other stuff that they didn't care about. Now, providing more choices there will, indisputably, add complexity, but it will also provide utility. What we're talking about here is not unlike what we went through with EXPLAIN syntax. We repeatedly rejected patches that might have added useful functionality to EXPLAIN on the grounds that (1) we didn't want to make new keywords and (2) even if we did add new keywords, extending the EXPLAIN productions would produce grammar conflicts. Then, we implemented the extensible-options stuff, and suddenly it became possible for people to write patches adding useful functionality to EXPLAIN that didn't get sunk before it got out of the gate, and since then we've gotten a new EXPLAIN option every release or two, and IMHO all of those options are pretty useful. Similarly, building a logging facility that meets the needs of real users is going to require a configuration method more flexible than a total order with four choices. I happen to think a list of comma-separated tokens is a pretty good choice, but something else could be OK, too. We need something better than what we've got now, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
