Thread: NOTICE vs WARNING
Can someone explain in succinct and general terms what the difference between a NOTICE and a WARNING is? I'm currently examining the validity of notice and warning messages throughout the backend, but I find these categories to be applied inconsistently. -- Peter Eisentraut peter_e@gmx.net
Surely a WARNING is a problem that you should probably fix? Or at least pay attention to. My thought is that you could turn of NOTICES and not worry. (Which is what I sometimes do during restore, etc.) Chris ----- Original Message ----- From: "Peter Eisentraut" <peter_e@gmx.net> To: "PostgreSQL Development" <pgsql-hackers@postgresql.org> Sent: Tuesday, August 26, 2003 12:44 AM Subject: [HACKERS] NOTICE vs WARNING > Can someone explain in succinct and general terms what the difference > between a NOTICE and a WARNING is? I'm currently examining the validity > of notice and warning messages throughout the backend, but I find these > categories to be applied inconsistently. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match >
Peter Eisentraut <peter_e@gmx.net> writes:
> Can someone explain in succinct and general terms what the difference
> between a NOTICE and a WARNING is? I'm currently examining the validity
> of notice and warning messages throughout the backend, but I find these
> categories to be applied inconsistently.
I'm sure they are :-(. WARNING was invented much later than NOTICE, and
I don't believe anyone tried to come up with a hard-and-fast distinction,
much less go through the code line-by-line to apply it consistently to
existing NOTICEs.
I'd say that WARNING means "this is probably wrong, you'd better take
a close look" while NOTICE is something that's probably OK but we want
to tell the user what we're doing. Dunno whether that's precise enough
though.
regards, tom lane
Christopher Kings-Lynne writes: > Surely a WARNING is a problem that you should probably fix? How are "should" and "probably" defined? > Or at least pay attention to. If it were in fact the characteristic of a NOTICE that you need not pay attention to them, why do we have them? > My thought is that you could turn of NOTICES and not worry. Well, there are plenty of NOTICE instances that carry a definite need to worry, such as identifier truncation, implicitly added FROM items, implicit changes to types specified as "opaque", unsupported and ignored syntax clauses. I have a slight feeling that these two categories cannot usefully be distinguished, but I'm interested to hear other opinions. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Well, there are plenty of NOTICE instances that carry a definite need to
> worry, such as identifier truncation, implicitly added FROM items,
> implicit changes to types specified as "opaque", unsupported and ignored
> syntax clauses.
Of course, some of those may be misclassified...
> I have a slight feeling that these two categories cannot usefully be
> distinguished, but I'm interested to hear other opinions.
I would say that NOTICEs are things that are routine in certain
contexts. We would not bother with the NOTICE at all if we thought
it held no interest, but often it doesn't have any.
Ignored syntax clauses probably ought to be WARNINGs, since the message
is telling you that what you asked for isn't going to be done. The
other examples you give seem appropriate as NOTICEs. In particular,
the notices about changing "opaque" types to something else are a
routine occurrence in upgrading old schemas, and so I think it's
reasonable for them to be NOTICEs.
regards, tom lane
> If it were in fact the characteristic of a NOTICE that you need not pay > attention to them, why do we have them? I have often wondered that myself. > > My thought is that you could turn off NOTICES and not worry. > > Well, there are plenty of NOTICE instances that carry a definite need to > worry, such as identifier truncation, implicitly added FROM items, > implicit changes to types specified as "opaque", unsupported and ignored > syntax clauses. I think that WARNING should be used for ALL things that have been deprecated. eg. implicit FROM, the opaque business, and definitely unsupported and ignored synacies. > I have a slight feeling that these two categories cannot usefully be > distinguished, but I'm interested to hear other opinions. Chris
Peter Eisentraut wrote: > Christopher Kings-Lynne writes: > > > Surely a WARNING is a problem that you should probably fix? > > How are "should" and "probably" defined? > > > Or at least pay attention to. > > If it were in fact the characteristic of a NOTICE that you need not pay > attention to them, why do we have them? > > > My thought is that you could turn of NOTICES and not worry. > > Well, there are plenty of NOTICE instances that carry a definite need to > worry, such as identifier truncation, implicitly added FROM items, > implicit changes to types specified as "opaque", unsupported and ignored > syntax clauses. > > I have a slight feeling that these two categories cannot usefully be > distinguished, but I'm interested to hear other opinions. The creation of a sequence during SERIAL creation is clearly a notice:test=> create table x(y serial);NOTICE: CREATE TABLEwill create implicit sequence "x_y_seq" for SERIALcolumn "x.y"CREATE TABLE That is what I used as a guide I think --- notices were things we want to tell you about, but you shouldn't be concerned about it. (Hey, I did it without using "probably"). -- 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
On Wed, 2003-08-27 at 00:07, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Christopher Kings-Lynne writes:
> >
> > > Surely a WARNING is a problem that you should probably fix?
> >
> > How are "should" and "probably" defined?
> >
> > > Or at least pay attention to.
> >
> > If it were in fact the characteristic of a NOTICE that you need not pay
> > attention to them, why do we have them?
> >
> > > My thought is that you could turn of NOTICES and not worry.
> >
> > Well, there are plenty of NOTICE instances that carry a definite need to
> > worry, such as identifier truncation, implicitly added FROM items,
> > implicit changes to types specified as "opaque", unsupported and ignored
> > syntax clauses.
> >
> > I have a slight feeling that these two categories cannot usefully be
> > distinguished, but I'm interested to hear other opinions.
>
> The creation of a sequence during SERIAL creation is clearly a notice:
>
> test=> create table x(y serial);
> NOTICE: CREATE TABLE will create implicit sequence "x_y_seq" for SERIAL
> column "x.y"
> CREATE TABLE
>
> That is what I used as a guide I think --- notices were things we want
> to tell you about, but you shouldn't be concerned about it. (Hey, I did
> it without using "probably").
>
I'll second this notion. Things like what is effected by DROP...CASCADE
and I believe that changing types from OPAQUE to TRIGGER fall into this
category as well. I'm trying to decide on the implicit FROM, iirc we now
have a GUC to turn this on/off, so it seems it should be a notice if
you've turned it on.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Wed, Aug 27, 2003 at 12:21:25 +0800, Christopher Kings-Lynne <chriskl@familyhealth.com.au> wrote: > > I think that WARNING should be used for ALL things that have been > deprecated. eg. implicit FROM, the opaque business, and definitely > unsupported and ignored synacies. Implicit froms aren't depreciated yet. For deletes there isn't any alternative syntax yet. There was some discussion about possible syntaxes, but nothing was done in this regard for 7.4.
On Wed, 27 Aug 2003, Bruno Wolff III wrote: > Implicit froms aren't depreciated yet. It would be really nice, to my mind, if they were killed stone dead. I've been bitten several times by having an implicit FROM added to a query that destroyed it. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.NetBSD.org Don't you know, in this new Dark Age, we're alllight. --XTC
Tom Lane writes: > I would say that NOTICEs are things that are routine in certain > contexts. We would not bother with the NOTICE at all if we thought > it held no interest, but often it doesn't have any. > > Ignored syntax clauses probably ought to be WARNINGs, since the message > is telling you that what you asked for isn't going to be done. The > other examples you give seem appropriate as NOTICEs. In particular, > the notices about changing "opaque" types to something else are a > routine occurrence in upgrading old schemas, and so I think it's > reasonable for them to be NOTICEs. My gut feeling was that of all things the messages about changing the opaque types should be warnings, because the effect of the command isn't exactly what you entered. A counterexample would be the notice about the creation of a sequence for serial, because in that case the effect of the command is exactly what you entered. I don't think the "routine occurrence" criterion scales well, because if you enter garbage, a syntax error is also a routine occurrence. In fact, I like the criterion that a warning should be raised rather than a notice if the effect of the command deviates from what the command actually says. That puts the messages for serials, primary keys, drop cascades clearly into notices, messages about missing, implicitly added, or changed syntax clauses into warnings. I don't think the dump reload scenario is particularly important. After all, psql or pg_restore don't act differently upon notice or warning, it's just something that the user reads. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> In fact, I like the criterion that a warning should be raised rather than
> a notice if the effect of the command deviates from what the command
> actually says.
Um. If I construe that literally, then the notices about identifier
truncation need to be warnings. I don't think I like that particular
answer. But as long as you're not too rigid about it, this might be
a reasonable approach.
regards, tom lane
> In fact, I like the criterion that a warning should be raised rather than > a notice if the effect of the command deviates from what the command > actually says. That puts the messages for serials, primary keys, drop > cascades clearly into notices, messages about missing, implicitly added, > or changed syntax clauses into warnings. > > I don't think the dump reload scenario is particularly important. After > all, psql or pg_restore don't act differently upon notice or warning, it's > just something that the user reads. WARNINGs don't cause transaction rollback, right? Cos if they did, changing NOTICEs to WARNINGs would cause pain. Chris
Christopher Kings-Lynne wrote: > > In fact, I like the criterion that a warning should be raised rather than > > a notice if the effect of the command deviates from what the command > > actually says. That puts the messages for serials, primary keys, drop > > cascades clearly into notices, messages about missing, implicitly added, > > or changed syntax clauses into warnings. > > > > I don't think the dump reload scenario is particularly important. After > > all, psql or pg_restore don't act differently upon notice or warning, it's > > just something that the user reads. > > WARNINGs don't cause transaction rollback, right? Cos if they did, changing > NOTICEs to WARNINGs would cause pain. No, only ERROR does transaction rollback. -- 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