Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
От | Vadim B. Mikheev |
---|---|
Тема | Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c') |
Дата | |
Msg-id | 34B066D2.27C8A703@sable.krasnoyarsk.su обсуждение исходный текст |
Ответ на | Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c') (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')
Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c') |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: