Bruce Momjian wrote:
>
> > > > 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.
>
If instead of printing:
ERROR: A parse error near "foo"
we print
ERROR: A parse error near "foo" (index=10)
it should not affect any of the existing clients.
For the clients, this will be just text as before and they will print it as
received. If some client wants, it may look for the index information and do
whatever is convenient for that interface (as an enhancement).
So I think this option is backward compatible.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
