Fabien COELHO wrote:
The current status of clients is that none of those I use will report
anything useful.
pgAdmin3's query tool will set a mark on the offending line.
Regards,
Andreas
---(end of broadcast)---
TIP 2: you can get off all lists
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> In particular, we determined that the appropriate place for this sort of
>> thing is on the client side, not in the backend.
> The current status of clients is that none of those I use will report
> anything useful.
So fix the clients. We have been th
> > (2) Does someone has any comment about these problems or
> > the way I intend to try to address them?
>
> About the implementation idea with hints. I'm not sure will be so easy to
> implement as you suggested. Maybe if one add hints to every construct,
> and set to empty hint where it does
> > (1) Lexical/syntax error source localisation
>
> > An extract of the offending source must be shown if possible along syntax
> > error messages.
>
> You would do well to go to the archives and read some of the previous
> discussion of these issues.
I'll do that.
> In particular, we determine
Fabien COELHO <[EMAIL PROTECTED]> writes:
> (1) Lexical/syntax error source localisation
> An extract of the offending source must be shown if possible along syntax
> error messages.
You would do well to go to the archives and read some of the previous
discussion of these issues. In particular,
On Thu, 4 Mar 2004, Fabien COELHO wrote:
> (1) Do postgresql "Masters" think this issue is worth being pursued, or
> any patch will be rejected as it is considered intrinsicly useless?
While I can't speak for others I would anyhow guess that everyone wants
better error messages. I know I wan
Dear Hackers,
Motivation
--
As a basic user of postgresql, I've been quite disappointed by the lack of
help provided by postgresql error messages dealing with syntax and
semantical errors, especially in long sql statements:
ERROR: syntax error at or near "(" at character 326
T
