Thread: how to get more detailed error messages?

Hi,

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.

This is a problem that we have with many other sql things, too. The line
number of the semicolon is the only thing we know. If we had the line number
of the error itself we could save much time. Alternatively, if we had the
name of the variables (in the case above) or a little quote of the problem
area, we would have much less trouble.

Isn't there a way to get the parser to talk more precisely???

Thank you very much,

Markus Wagner

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

Tom,

> 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.

I'd suggest it as a compile-time option, if that's feasable.  This is
only a concern, IME, for development machines.  On a production
machine, presumably all of the queries and functions are already
tested.

Thus, if we had the compile-time option of --explicit-query-errors then
it would add this functionality for testers without slowing down
PostgreSQL overall.  Don't know if compile-time options for the parser
are reasonable, though.  Also, I would personally rate this below
several other improvement projects in priority, such as in-database
replication, point-in-time recovery and nested transactions.

-Josh Berkus

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