Обсуждение: Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
On Sat, 3 Jan 1998, Bruce Momjian wrote: > Sounds maybe a little too serious. We currently use WARN a lot to > indicate errors in the supplied SQL statement. Perhaps we need to make > the parser elog's ERROR, and the non-parser WARN's ABORT? Is that good? > When can I make the change? I don't want to mess up people's current work. This shouldn't affect JDBC. The only thing that would break things, is if the notification sent by the "show datestyle" statement is changed. -- Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk Main Homepage: http://www.demon.co.uk/finder Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
> > Mattias Kregert wrote: > > > > Bruce Momjian wrote: > > > > > > > > I just think the WARN word coming up on users terminals is odd. I can > > > make the change in all the source files easily if we decide what the new > > > error word should be. Error? Failure? > > > > > > > Yes, that's one of the things I don't understand with PostgreSQL. > > ERROR would be much better. > > How about ABORT ? So I assume no one has pending patches where this change would cause a problem. So I will go ahead. -- Bruce Momjian maillist@candle.pha.pa.us
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Vadim B. Mikheev"
Дата:
Bruce Momjian wrote: > > > > > Mattias Kregert wrote: > > > > > > Bruce Momjian wrote: > > > > > > > > > > > I just think the WARN word coming up on users terminals is odd. I can > > > > make the change in all the source files easily if we decide what the new > > > > error word should be. Error? Failure? > > > > > > > > > > Yes, that's one of the things I don't understand with PostgreSQL. > > > ERROR would be much better. > > > > How about ABORT ? > > Sounds maybe a little too serious. We currently use WARN a lot to > indicate errors in the supplied SQL statement. Perhaps we need to make > the parser elog's ERROR, and the non-parser WARN's ABORT? Is that good? > When can I make the change? I don't want to mess up people's current work. ABORT means that transaction is ABORTed. Will ERROR mean something else ? Why should we use two different flag-words for the same thing ? Note, that I don't object against using ERROR, but against using two words. Vadim
> ABORT means that transaction is ABORTed. > Will ERROR mean something else ? > Why should we use two different flag-words for the same thing ? > Note, that I don't object against using ERROR, but against using two words. I wanted two words to distinguish between user errors like a mis-spelled field name, and internal errors like btree failure messages. Make sense? I made all the error messages coming from the parser as ERROR, and non-parser messages as ABORT. I think I will need to fine-tune the messages because I am sure I missed some messages that should be ERROR but are ABORT. For example, utils/adt messages about improper data formats, is that an ERROR or an ABORT? -- Bruce Momjian maillist@candle.pha.pa.us
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Vadim B. Mikheev"
Дата:
Bruce Momjian wrote: > > > ABORT means that transaction is ABORTed. > > Will ERROR mean something else ? > > Why should we use two different flag-words for the same thing ? > > Note, that I don't object against using ERROR, but against using two words. > > I wanted two words to distinguish between user errors like a mis-spelled > field name, and internal errors like btree failure messages. > > Make sense? No, for me. Do Informix, Oracle, etc use two words ? What benefit of special "in-parser-error" word for user - in any case user will read error message itself to understand what caused error. > > I made all the error messages coming from the parser as ERROR, and > non-parser messages as ABORT. I think I will need to fine-tune the > messages because I am sure I missed some messages that should be ERROR > but are ABORT. For example, utils/adt messages about improper data > formats, is that an ERROR or an ABORT? Good question :) Following your way insert into X (an_int2_field) values (9999999999); should cause ERROR message, but insert into X (an_int2_field) select an_int4_field from Y; should return ABORT message if value of some an_int4_field in Y is greater than 32768. Vadim
> > Bruce Momjian wrote: > > > > > ABORT means that transaction is ABORTed. > > > Will ERROR mean something else ? > > > Why should we use two different flag-words for the same thing ? > > > Note, that I don't object against using ERROR, but against using two words. > > > > I wanted two words to distinguish between user errors like a mis-spelled > > field name, and internal errors like btree failure messages. > > > > Make sense? > > No, for me. Do Informix, Oracle, etc use two words ? > What benefit of special "in-parser-error" word for user - in any case > user will read error message itself to understand what caused error. OK, if no one likes my idea in the next day, I will make them all ERROR. -- Bruce Momjian maillist@candle.pha.pa.us
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Thomas G. Lockhart"
Дата:
> > > I wanted two words to distinguish between user errors like a mis-spelled > > > field name, and internal errors like btree failure messages. > > > > > > Make sense? > > > > No, for me. Do Informix, Oracle, etc use two words ? > > What benefit of special "in-parser-error" word for user - in any case > > user will read error message itself to understand what caused error. > > OK, if no one likes my idea in the next day, I will make them all ERROR. Well, _I_ like your idea. Seems like we can distinguish between operator error (which the operator can fix) and internal problems, and we could flag them differently. Perhaps there are so many grey areas that this becomes difficult to do?? - Tom
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Vadim B. Mikheev"
Дата:
Thomas G. Lockhart wrote: > > > > > I wanted two words to distinguish between user errors like a mis-spelled > > > > field name, and internal errors like btree failure messages. > > > > > > > > Make sense? > > > > > > No, for me. Do Informix, Oracle, etc use two words ? > > > What benefit of special "in-parser-error" word for user - in any case > > > user will read error message itself to understand what caused error. > > > > OK, if no one likes my idea in the next day, I will make them all ERROR. > > Well, _I_ like your idea. Seems like we can distinguish between operator error > (which the operator can fix) and internal problems, and we could flag them > differently. Perhaps there are so many grey areas that this becomes difficult to > do?? All adt/*.c are "grey areas": insert into X (an_int2_field) values (9999999999); should cause ERROR message, but insert into X (an_int2_field) select an_int4_field from Y; should return ABORT message if value of some an_int4_field in Y is greater than 32768. Vadim
> > I made all the error messages coming from the parser as ERROR, and > > non-parser messages as ABORT. I think I will need to fine-tune the > > messages because I am sure I missed some messages that should be ERROR > > but are ABORT. For example, utils/adt messages about improper data > > formats, is that an ERROR or an ABORT? > > Good question :) > > Following your way > > insert into X (an_int2_field) values (9999999999); > > should cause ERROR message, but > > insert into X (an_int2_field) select an_int4_field from Y; This generates an ERROR, because the parser catches the type mismatch. It looks like the changes are broken up pretty much among directories. utils/adt and catalog/ and commands/ are all pretty much ERROR. > > should return ABORT message if value of some an_int4_field in Y is > greater than 32768. > > Vadim > -- Bruce Momjian maillist@candle.pha.pa.us
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Vadim B. Mikheev"
Дата:
Bruce Momjian wrote: > > > > I made all the error messages coming from the parser as ERROR, and > > > non-parser messages as ABORT. I think I will need to fine-tune the > > > messages because I am sure I missed some messages that should be ERROR > > > but are ABORT. For example, utils/adt messages about improper data > > > formats, is that an ERROR or an ABORT? > > > > Good question :) > > > > Following your way > > > > insert into X (an_int2_field) values (9999999999); > > > > should cause ERROR message, but > > > > insert into X (an_int2_field) select an_int4_field from Y; > > This generates an ERROR, because the parser catches the type mismatch. Hm - this is just example, I could use casting here... Vadim
> > This generates an ERROR, because the parser catches the type mismatch. > > Hm - this is just example, I could use casting here... Ah, you got me here. If you cast int2(), you would get a different message. You are right. I changes parser/, commands/, utils/adt/, and several of the /tcop files. Should take care of most of them. Any errors coming out of the optimizer or executor, or cache code should be marked as serious. Let's see if it helps. I can easily make them all the same. -- Bruce Momjian maillist@candle.pha.pa.us
On Fri, 2 Jan 1998, Bruce Momjian wrote: > > > > Bruce Momjian wrote: > > > > > > > > I just think the WARN word coming up on users terminals is odd. I can > > > make the change in all the source files easily if we decide what the new > > > error word should be. Error? Failure? > > > > > > > Yes, that's one of the things I don't understand with PostgreSQL. > > ERROR would be much better. > > > > It would be even better if the backend would have an option to > > log all messages via syslog. That would be much easier, especially > > if you use syslog to send log messages to a separate log server, or > > if you want different types of messages to go to different locations, > > like FATAL to a console, WARN to a file somewhere and so on. > > Syslog functionality is on the TODO list. Mark me down for it... ------------------------------
> > Mattias Kregert wrote: > > > > Bruce Momjian wrote: > > > > > > > > I just think the WARN word coming up on users terminals is odd. I can > > > make the change in all the source files easily if we decide what the new > > > error word should be. Error? Failure? > > > > > > > Yes, that's one of the things I don't understand with PostgreSQL. > > ERROR would be much better. > > How about ABORT ? Sounds maybe a little too serious. We currently use WARN a lot to indicate errors in the supplied SQL statement. Perhaps we need to make the parser elog's ERROR, and the non-parser WARN's ABORT? Is that good? When can I make the change? I don't want to mess up people's current work. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
> > Syslog functionality is on the TODO list. > > Mark me down for it... Updated TODO list. [Recently, someone yelled at me for not trimming my replies.] - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
> > On Fri, 2 Jan 1998, Bruce Momjian wrote: > > > > > [Recently, someone yelled at me for not trimming my replies.] > > *hangs head in shame* > > No, someone properly yelled at me for just putting a reply at the top of the message, and leaving >100 lines of text after it. I have since learned to be more considerate. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------ End of hackers-digest V1 #593 *****************************
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Vadim B. Mikheev"
Дата:
Mattias Kregert wrote: > > Bruce Momjian wrote: > > > > > I just think the WARN word coming up on users terminals is odd. I can > > make the change in all the source files easily if we decide what the new > > error word should be. Error? Failure? > > > > Yes, that's one of the things I don't understand with PostgreSQL. > ERROR would be much better. How about ABORT ? Vadim ------------------------------
On Sat, 3 Jan 1998, Bruce Momjian wrote: > Sounds maybe a little too serious. We currently use WARN a lot to > indicate errors in the supplied SQL statement. Perhaps we need to make > the parser elog's ERROR, and the non-parser WARN's ABORT? Is that good? > When can I make the change? I don't want to mess up people's current work. This shouldn't affect JDBC. The only thing that would break things, is if the notification sent by the "show datestyle" statement is changed. - -- Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk Main Homepage: http://www.demon.co.uk/finder Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk ------------------------------
> ABORT means that transaction is ABORTed. > Will ERROR mean something else ? > Why should we use two different flag-words for the same thing ? > Note, that I don't object against using ERROR, but against using two words. I wanted two words to distinguish between user errors like a mis-spelled field name, and internal errors like btree failure messages. Make sense? I made all the error messages coming from the parser as ERROR, and non-parser messages as ABORT. I think I will need to fine-tune the messages because I am sure I missed some messages that should be ERROR but are ABORT. For example, utils/adt messages about improper data formats, is that an ERROR or an ABORT? - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
> > Mattias Kregert wrote: > > > > Bruce Momjian wrote: > > > > > > > > I just think the WARN word coming up on users terminals is odd. I can > > > make the change in all the source files easily if we decide what the new > > > error word should be. Error? Failure? > > > > > > > Yes, that's one of the things I don't understand with PostgreSQL. > > ERROR would be much better. > > How about ABORT ? So I assume no one has pending patches where this change would cause a problem. So I will go ahead. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
> > Bruce Momjian wrote: > > > > > I just think the WARN word coming up on users terminals is odd. I can > > make the change in all the source files easily if we decide what the new > > error word should be. Error? Failure? > > > > Yes, that's one of the things I don't understand with PostgreSQL. > ERROR would be much better. > > It would be even better if the backend would have an option to > log all messages via syslog. That would be much easier, especially > if you use syslog to send log messages to a separate log server, or > if you want different types of messages to go to different locations, > like FATAL to a console, WARN to a file somewhere and so on. Syslog functionality is on the TODO list. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
On Fri, 2 Jan 1998, Bruce Momjian wrote: > > [Recently, someone yelled at me for not trimming my replies.] *hangs head in shame* ------------------------------
Bruce Momjian wrote: > > I just think the WARN word coming up on users terminals is odd. I can > make the change in all the source files easily if we decide what the new > error word should be. Error? Failure? > Yes, that's one of the things I don't understand with PostgreSQL. ERROR would be much better. It would be even better if the backend would have an option to log all messages via syslog. That would be much easier, especially if you use syslog to send log messages to a separate log server, or if you want different types of messages to go to different locations, like FATAL to a console, WARN to a file somewhere and so on. /* m */ ------------------------------
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Vadim B. Mikheev"
Дата:
Bruce Momjian wrote: > > > > > Mattias Kregert wrote: > > > > > > Bruce Momjian wrote: > > > > > > > > > > > I just think the WARN word coming up on users terminals is odd. I can > > > > make the change in all the source files easily if we decide what the new > > > > error word should be. Error? Failure? > > > > > > > > > > Yes, that's one of the things I don't understand with PostgreSQL. > > > ERROR would be much better. > > > > How about ABORT ? > > Sounds maybe a little too serious. We currently use WARN a lot to > indicate errors in the supplied SQL statement. Perhaps we need to make > the parser elog's ERROR, and the non-parser WARN's ABORT? Is that good? > When can I make the change? I don't want to mess up people's current work. ABORT means that transaction is ABORTed. Will ERROR mean something else ? Why should we use two different flag-words for the same thing ? Note, that I don't object against using ERROR, but against using two words. Vadim ------------------------------
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Vadim B. Mikheev"
Дата:
Thomas G. Lockhart wrote: > > > > > I wanted two words to distinguish between user errors like a mis-spelled > > > > field name, and internal errors like btree failure messages. > > > > > > > > Make sense? > > > > > > No, for me. Do Informix, Oracle, etc use two words ? > > > What benefit of special "in-parser-error" word for user - in any case > > > user will read error message itself to understand what caused error. > > > > OK, if no one likes my idea in the next day, I will make them all ERROR. > > Well, _I_ like your idea. Seems like we can distinguish between operator error > (which the operator can fix) and internal problems, and we could flag them > differently. Perhaps there are so many grey areas that this becomes difficult to > do?? All adt/*.c are "grey areas": insert into X (an_int2_field) values (9999999999); should cause ERROR message, but insert into X (an_int2_field) select an_int4_field from Y; should return ABORT message if value of some an_int4_field in Y is greater than 32768. Vadim ------------------------------
> > I made all the error messages coming from the parser as ERROR, and > > non-parser messages as ABORT. I think I will need to fine-tune the > > messages because I am sure I missed some messages that should be ERROR > > but are ABORT. For example, utils/adt messages about improper data > > formats, is that an ERROR or an ABORT? > > Good question :) > > Following your way > > insert into X (an_int2_field) values (9999999999); > > should cause ERROR message, but > > insert into X (an_int2_field) select an_int4_field from Y; This generates an ERROR, because the parser catches the type mismatch. It looks like the changes are broken up pretty much among directories. utils/adt and catalog/ and commands/ are all pretty much ERROR. > > should return ABORT message if value of some an_int4_field in Y is > greater than 32768. > > Vadim > - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
> > This generates an ERROR, because the parser catches the type mismatch. > > Hm - this is just example, I could use casting here... Ah, you got me here. If you cast int2(), you would get a different message. You are right. I changes parser/, commands/, utils/adt/, and several of the /tcop files. Should take care of most of them. Any errors coming out of the optimizer or executor, or cache code should be marked as serious. Let's see if it helps. I can easily make them all the same. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Vadim B. Mikheev"
Дата:
Bruce Momjian wrote: > > > ABORT means that transaction is ABORTed. > > Will ERROR mean something else ? > > Why should we use two different flag-words for the same thing ? > > Note, that I don't object against using ERROR, but against using two words. > > I wanted two words to distinguish between user errors like a mis-spelled > field name, and internal errors like btree failure messages. > > Make sense? No, for me. Do Informix, Oracle, etc use two words ? What benefit of special "in-parser-error" word for user - in any case user will read error message itself to understand what caused error. > > I made all the error messages coming from the parser as ERROR, and > non-parser messages as ABORT. I think I will need to fine-tune the > messages because I am sure I missed some messages that should be ERROR > but are ABORT. For example, utils/adt messages about improper data > formats, is that an ERROR or an ABORT? Good question :) Following your way insert into X (an_int2_field) values (9999999999); should cause ERROR message, but insert into X (an_int2_field) select an_int4_field from Y; should return ABORT message if value of some an_int4_field in Y is greater than 32768. Vadim ------------------------------
> > Bruce Momjian wrote: > > > > > ABORT means that transaction is ABORTed. > > > Will ERROR mean something else ? > > > Why should we use two different flag-words for the same thing ? > > > Note, that I don't object against using ERROR, but against using two words. > > > > I wanted two words to distinguish between user errors like a mis-spelled > > field name, and internal errors like btree failure messages. > > > > Make sense? > > No, for me. Do Informix, Oracle, etc use two words ? > What benefit of special "in-parser-error" word for user - in any case > user will read error message itself to understand what caused error. OK, if no one likes my idea in the next day, I will make them all ERROR. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Vadim B. Mikheev"
Дата:
Bruce Momjian wrote: > > > > I made all the error messages coming from the parser as ERROR, and > > > non-parser messages as ABORT. I think I will need to fine-tune the > > > messages because I am sure I missed some messages that should be ERROR > > > but are ABORT. For example, utils/adt messages about improper data > > > formats, is that an ERROR or an ABORT? > > > > Good question :) > > > > Following your way > > > > insert into X (an_int2_field) values (9999999999); > > > > should cause ERROR message, but > > > > insert into X (an_int2_field) select an_int4_field from Y; > > This generates an ERROR, because the parser catches the type mismatch. Hm - this is just example, I could use casting here... Vadim ------------------------------
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От
"Thomas G. Lockhart"
Дата:
> > > I wanted two words to distinguish between user errors like a mis-spelled > > > field name, and internal errors like btree failure messages. > > > > > > Make sense? > > > > No, for me. Do Informix, Oracle, etc use two words ? > > What benefit of special "in-parser-error" word for user - in any case > > user will read error message itself to understand what caused error. > > OK, if no one likes my idea in the next day, I will make them all ERROR. Well, _I_ like your idea. Seems like we can distinguish between operator error (which the operator can fix) and internal problems, and we could flag them differently. Perhaps there are so many grey areas that this becomes difficult to do?? - Tom ------------------------------