Re: [SQL] how to get more detailed error messages?
От | Richard Emberson |
---|---|
Тема | Re: [SQL] how to get more detailed error messages? |
Дата | |
Msg-id | 3CB72553.A7037D96@phc.net обсуждение исходный текст |
Ответ на | how to get more detailed error messages? (Markus Wagner <wagner@imsd.uni-mainz.de>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: