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

From: "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su>
To: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, matti(at)algonet(dot)se, hackers(at)postgresql(dot)org
Subject: Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')
Date: 1998-01-05 07:48:59
Message-ID: 34B0906A.81B11AFF@sable.krasnoyarsk.su
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-01-05 07:56:07 Re: [HACKERS] why is char now a keyword
Previous Message Thomas G. Lockhart 1998-01-05 07:12:11 Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c')