On Fri, Jun 20, 2014 at 9:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@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
