Gavin Sherry wrote:
> 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.
What do people think? I thought we needed a way to turn this off,
especially if the queries can be large. Because ERROR is above LOG in
server_min_messages, I don't think that is a way to fix it.
> 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.
I thought it was good you could merge them, but now I remember why I
didn't --- they take different args.
>
> 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
You can't do the hack.
> 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.
I think the second, passing an arg to say whether it is server or
client, will do the trick, though now you need an error one too. I
guess you have to use #define and set it, or pass a string down with the
GUC variable and test that with strcmp.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
