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 по дате отправления: