On Mon, 2 Sep 2002, Bruce Momjian wrote:
> > >> Oh, didn't you put in that patch to provide a GUC level control?
> >
> > > Yes, but what level do you set it at to turn it off?
> >
> > FATAL? PANIC?
>
> He doesn't support those levels:
>
> test=> set log_min_error_statement = fatal;
> ERROR: invalid value for option 'log_min_error_statement': 'fatal'
> test=> set log_min_error_statement = error;
> SET
>
> and in fact, the default is ERROR. I think the default has to be
> something higher, but even FATAL seems wrong. We have to be able to
> turn it off, and have it off by default, rather than saying it only
> happens with fatal errors or something like that.
Okay, my bad. From my reading of the email exchange, I thought people
wanted this on -- always. The best solution for this, in my opinion, is to
have a magic value "off" which the error code lookup translates to some
number > PANIC.
Secondly, there is a flaw in the patch. I merged all the
assign_server_min_messages() and assign_client_min_messages() code to make
things pretty. Perhaps I shouldn't have (since I left off FATAL and PANIC
from the list, which I shouldn't have for the prior but should have for
the latter). So there are a few ways to fix it: allow both functions (+
the log_min_error_state function) to accept all possible error codes +
"off" (which does nothing for the first two functions); pass a unique
number for each function to assign_msglvl() so that we can determine the
a legal error code for that GUC variable is being assigned; or, just have
different lists.
Now, the first solution is a hack, but it shouldn't actually break
anything. The second is overkill. The third is the best way to do it but
as we add more of these kinds of functions (log_min_parse,
log_min_rewritten? -- I can a use for that) the amount of assign_ code
will grow linearly and be pretty similar.
Ideas?
Gavin
