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 want it.
I spend a fair amount of time on irc helping people with all kinds of
postgresql problems, and it's not uncommon that people need help to
understand the error messages. It's not hard to understand them for people
who are "in the game", but for others it can be difficult.
> (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 not make sense.
What I'm afraid of is to get hints or advices that are plain wrong. If
that happens a lot it's better to not have hints at all. Like for this:
CREATE TABLE foo (bar int key);
and gettting an error
CREATE TABLE foo (bar int key);
^
HINT: table name expected
or something.
But if it works good in practice, why not having hints.
Another thing one can add to make better errors are rules that handle
typical errors, like:
stmt:
CREATE TABLE ( anything ); { generate error "missing table name" }
--
/Dennis Björklund
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
