| From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
|---|---|
| To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su>, 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:12:11 |
| Message-ID: | 34B087CA.D348D05B@alumni.caltech.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vadim B. Mikheev | 1998-01-05 07:48:59 | Re: Error messages/logging (Was: Re: [HACKERS] Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y parse_oper.c') |
| Previous Message | Edmund Mergl | 1998-01-05 06:07:37 | why is char now a keyword |