> > > 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.
>
> But how do they display error messages now? Can't they just continue
> doing that with this new code? Do we want to make them code their own
> error handling, and for what little benefit? Let them figure out how to
> display the error in fixed-width font and be done with it. I am sure
> they have bigger things to do than colorize error locations.
A bigger question is that if we decide to output just offset information
in the message, we have to be sure _all_ the clients can interpret it or
the syntax information is confusing. Are we prepared to get all the
clients update at the same time we add the feature? Seems we should go
with a simple solution now and add later.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
