Re: Patch for Improved Syntax Error Reporting - Mailing list pgsql-patches

From Tom Lane
Subject Re: Patch for Improved Syntax Error Reporting
Date
Msg-id 11139.996695423@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch for Improved Syntax Error Reporting  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Patch for Improved Syntax Error Reporting  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom, it is hard to imagine how they would even find relevant stuff on
> this issue.  The TODO.detail item is very vague.

I dunno that it's vague --- a quick look indicates that TODO.detail/elog
has most of the recent messages on the subject.  (Neil, the "recent
discussion" that I referred to seems to be in there, or most of it
anyway, if you didn't see it in the archives yet.)

> In fact, their solution is an improvement over what is in
> TODO.detail/yacc now.

Agreed, the idea of pulling out just the one line is an improvement over
the last patch.  It's still going down the wrong path though.  We should
be empowering client apps to highlight syntax errors properly, not
presenting edited info in a way that might be useful to humans but will
be unintelligible to programs.  If we go that route, it will be harder
to do the right thing later.

> I know some people like a client-independent way of displaying errors,
> but I like the direct approach of this patch, returning a string with
> the error line highlighted and the location marked.  I don't want to
> push added complexity into the client, especially when we don't even
> have a client who has this need yet.

pgAdmin, phpAdmin, pgaccess, and friends don't count?  We have GUI front
ends *today*, you know.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch for Improved Syntax Error Reporting
Next
From: Neil Padgett
Date:
Subject: Re: Revised Patch to allow multiple table locks in "Unison"