Dave Page <dpage@vale-housing.co.uk> writes:
> I disagree. In pgAdmin's case, if the user enters an SQL query, pgAdmin will
> rewrite it to remove any formatting that the user has entered before it's
> sent to the backend. This means that the query sent may (== often is)
> shorter than the query entered by the user where carriage returns etc. have
> been removed, hence the index value would just be confusing to the user as
> it may well be wrong.
This strikes me as a perfect example of the situation where the frontend
application *must* take some of the responsibility for displaying a
proper location for a syntax error. Once you've rewritten the query
like that, a patch such as Neil's original effort would be unlikely to
produce anything particularly helpful to the user. For example: does
your reformatting include collapsing out whitespace, eg reducing
newlines to spaces? If so, Neil's assumption that one line surrounding
the error point is the right amount of context will fail badly.
I think if you want to do that sort of thing then it's up to you to
maintain the mapping between what the user typed and what you actually
sent to the backend, so that you can reverse it to interpret the query
offset, and finally display an error that points at the right place in
text that the user really typed.
Memo to Neil: I believe you'll find that even psql does a certain amount
of this --- IIRC, it strips out SQL comments, for instance.
regards, tom lane