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 should give 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 token if available (for better hilighting?)
this is basically the current P, but not meant to the user,
and with possible additions.

- 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 difference in 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 contains sql.

the client may open an editor for plpgsql function of it sees it fits...
or whatever. The information is available, that is the point.

Have a nice day,

--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr