Josh Berkus <josh@agliodbs.com> writes:
> Actually, I can see that ... what about an option like "log_statement" which
> took an array of text which would correspond to the first part of the
> statement? Then we could leave it up to the DBA do decide what they want to
> log, with the validation list being the base list of SQL statements, i.e.:
> log_statement = "CREATE TABLE, ALTER TABLE, CREATE VIEW, ALTER VIEW"
Strikes me as a tad unwieldy --- the useful cases would correspond to
very long log_statement lists, and in every new release the list would
change. It's probably better to have a very small number of categories,
something likeSELECTINSERT/UPDATE/DELETEall DDL
and be able to flip logging on/off per category. But we need to think
about exactly what the categories are.
A related point that I've been meaning to bring up is that I'm not sure
what sort of logging ought to happen in the new FE/BE protocol's
PARSE/BIND/EXECUTE universe. Right now, if you've got log_statement on,
the strings fed to PARSE get logged. But that's got precious little to
do with what gets executed when, if the client is actually exploiting
the opportunity to prepare statements in advance of execution. On the
other hand, I'm not sure we want three log entries for every command.
Any thoughts on this out there?
regards, tom lane