Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')

Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>

From: "Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
To: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Cc: Bruce Momjian <maillist@candle.pha.pa.us>, matti@algonet.se, hackers@postgresql.org
Date: 1998-01-05T07:48:59Z
Lists: pgsql-hackers
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