> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 02 August 2001 22:12
> To: Dave Page
> Cc: 'Fernando Nasser'; Bruce Momjian; Neil Padgett;
> pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] Patch for Improved Syntax Error Reporting
>
>
> 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.
Yes, I agree that it is partially pgAdmin's fault if it all falls over.
However, pgAdmin does pretty much just the reformatting you've suggested,
including stripping of comments (well that's in the new codebase anyway),
so:
-- Simple Query
SELECT
oid,
relname
FRUM
pg_class
becomes:
SELECT oid, relname FRUM pg_class
Giving the error
ERROR: parser: parse error at or near 'frum':
SELECT oid, relname FRUM pg_class
^
Which would still be useful of course.
Regards, Dave.
