Re: Syntax error reporting (was Re: [PATCHES] syntax error position

Dear Tom,

> The point is that CONTEXT is essentially a record of "how we got here".

Yes, but for human eyes.

> In a situation where the actual error occurs inside a couple of levels
> of nesting, you want to be able to report the outer queries as well as
> the one that directly caused the error.  I agree that there's probably
> little hope of clients automatically making sense of the CONTEXT info.
> But we need to provide it to help people debug complex functions.

Yes.

> > More over, I have other ideas for CONTEXT, which should really be a stack.
> It already is a stack.

Ok, I agree that there is a "push", but I'm still looking fot the "pop".

Maybe I missed something, but it seemed to me that strings are appended
on to the other, and there is no way back.

That's what I mean by a "real" stack. If a student of mine comes to me
with his or her "stack" without a "pop", he or she will not have a very
good grade;-)

So when more information are to be fed into the context, they are to be
fed when they are actually needed on the error, maybe with callbacks?
They cannot be fed prevently.

What I would have looked for, is a stack on which functions could push
and pop informations as they want, so that the stack would be always
available for any error or warning or debug trace down the callgraph.

If it is the case already, as I said above, I haven't seen the "pop"
feature yet.

> > I think a new field is alas necessary.
> I'm leaning in that direction also.  How about
> 'P': used only for syntax error position in the client-submitted query.
> 'p': syntax error position in an internally-generated query.
> 'q': text of an internally-generated query ('p' and 'q' would always
>      appear together).

Why not.

Taking your very idea a little step further, I would suggest the
following, which is pretty similar, but even more general:

1/ field conventions:
 - upper case letter fields are for humans.   they are meant to be shown to the user, even new ones?
 - lower case letter fields are for machines / clients   they are never meant to be shown to the user!   but they
shouldgive some information to the client on how to   process an error report.
 

2/ new fields:
- p: character [length] [reserved for future use]  where the "parser error" occured, with the length of the  offending
tokenif available (for better hilighting?)  this is basically the current P, but not meant to the user,  and with
possibleadditions.
 
- q: select foo frm bla; the raw sql query that was being processed, whatever the case. I think syntax error are rare
occurences,so it is no big deal to return the query anyway. this may make some clients code easier because there is no
differencein the processing for different kind of errors.
 
- c: context-description some context for the client, not the human, so no localisation. something like:  c: lang=sql
query c: lang=sql query-part  c: lang=sql function 'foo' 4
 
 it could be adapted to other syntax errors, something like.
  c: lang=plpgsql function 'foo' 4  c: lang=perl function 'bla' 43
 or separate fields: l:sql for the language, f: for the function... in such cases, the q: field would not necessarily
containssql.
 
 the client may open an editor for plpgsql function of it sees it fits... or whatever. The information is available,
thatis the point.
 

Have a nice day,

-- 
Fabien Coelho - coelho@cri.ensmp.fr