Re: Patch for Improved Syntax Error Reporting

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch for Improved Syntax Error Reporting
Дата
Msg-id 29180.996944124@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: Patch for Improved Syntax Error Reporting  (Dave Page <dpage@vale-housing.co.uk>)
Ответы Re: Patch for Improved Syntax Error Reporting
Список pgsql-patches
Dave Page <dpage@vale-housing.co.uk> writes:
> Oh, I quite agree. I'm not adverse to updating my code, I just want to avoid
> users getting misleading messages until I come up with those updates.

Hmm ... if they were actively misleading then I'd share your concern.

I guess what you're thinking is that the error offset reported by the
backend won't correspond directly to what the user typed, and if the
user tries to use the offset to manually count off characters, he may
arrive at the wrong place?  Good point.  I'm not sure whether a message
like

    ERROR:  parser: parse error at or near 'frum';
    POSITION: 42

would be likely to encourage people to try that.  Thoughts?  (I do think
this is a good argument for not embedding the position straight into the
main error message though...)

One possible compromise is to combine the straight character-offset
approach with a simplistic context display:

    ERROR:  parser: parse error at or near 'frum';
    POSITION: 42  ... oid,relname FRUM ...

The idea is to define the "POSITION" field as an integer offset possibly
followed by whitespace and noise words.  An updated client would grab
the offset, ignore the rest of the field, and do the right thing.  A
not-updated client would display the entire message, and with any luck
the user would read it correctly.

            regards, tom lane

В списке pgsql-patches по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: RE: Patch for Improved Syntax Error Reporting
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: [BUGS] WIN32 Non Blocking