From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: I am done |
Date: | 2002-09-05 15:51:28 |
Message-ID: | 200209051551.g85FpSY12309@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > But the client side doesn't make any sense to support FATAL. Am I
> > missing something?
>
> Hm. I suppose a client setting above ERROR might break some application
> programs that expect either ERROR or a command-complete response ...
> but do we need to go out of our way to prohibit people from choosing
> settings that break their clients? If so, I've got a long list of
> things we'd better worry about ...
client_min_messages currently shows:
#client_min_messages = notice # Values, in order of decreasing detail:
# debug5, debug4, debug3, debug2, debug1,
# log, info, notice, warning, error
so it is only fatal and panic that are not allowed for clients. If you
want to allow them, that is fine with me. It would make it more
consistent, but of course I don't think a fatal or panic ever makes it
to the client side.
Your point that there should be a way of eliminating even ERROR coming
to a client seems valid to me. Let's make the change.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Manuel Sugawara | 2002-09-05 16:08:02 | Re: beta1 packaged |
Previous Message | Tom Lane | 2002-09-05 15:40:35 | Re: I am done |