When an error occurs in the parser, have the parser inform the top-level
(whatever that is)
and the query is reparsed this time keeping the context information so that a
more
meaningful error message maybe generated.
This has the overhead of setting up the catch block (I guess it would be a
longjmp)
and also the parser would have to check a flag to see if context information
(backpointers)
should be generated - unless you have two versions of the parser ... compile
time flags.
Richard
Tom Lane wrote:
> Markus Wagner <wagner@imsd.uni-mainz.de> writes:
> > we have a union query over three select queries with some hundred lines of
> > SQL code, created as a view.
>
> > When executing the code we get an error message "ERROR: UNION types "text"
> > and "int4" not matched" with only the line number of the terminating
> > semicolon included.
>
> > Isn't there a way to get the parser to talk more precisely???
>
> Not at present. This sort of error comes from deep inside the parser;
> the code is working with a querytree that does not have any direct
> connection anymore to source text. Line numbers are not to be had,
> and your suggestion of variable names is rather pointless also, at
> least for this example --- there's no guarantee that the expressions
> causing the problem involve any variables at all.
>
> I have occasionally toyed with the idea of labeling querytree elements
> with back-pointers showing the segment of source text that they came
> from, but AFAICT this would impose a nontrivial cost on parsing activity
> --- a cost that'd be paid all the time, even on correct queries. Not
> sure if it'd be a net benefit or not.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html