hint infrastructure setup (v2)

Dear patchers,

As I see that my previous attempt has met a lot of reactions;-)

Please find attached my SECOND patch proposition which sets an initial
"hint" infrastructure into the sql parser. At the time it is pretty simple
as I'm not yet convinced yet that I'll need a "hint stack" or something
like that to cope with recursions, despite initial implementations I've
already tried.

The patch adds a "current_hint" variable in the parser which is to be
updated by syntax rules as needed. If the variable is not NULL on a syntax
error, the hint is displayed with the HINT tag already included in the
error reporting functions, otherwise nothing happens. Also a new file
about hints is added to the validation, but is not added to the default
regression tests.

It also adds a new client option "parser_error_hints" which is false by
default, and which governs whether hints are shown on parser errors. I've
added this option and this default after a mail by several DBAs on the
hacker lists who considers WARNING and NOTICE basically "crazy" things.
My agenda is to help my students while learning SQL with postgreSQL, but I
can understand that some people don't like being helped. So this option is
an attempt at resolving the contradiction.

The current status is that, if the option is set to true, an initial hint
is provided, and then no hints are available thanks to added stop-hint
rules.

My intent is to submit later new small incremental patches on this
infrastructure so as to provide hints in various cases, typically for
every sql commands such as "CREATE USER", "DROP TABLE" and so on.

My motivation not to submit a full patch is that:

(1) It is a lot of work not likely to be finished quickly.
As I work on that, it is pretty sure that the "gram.y" file
will have been updated and thus there will be conflicts.

(2) It would basically result in a drop-in replacement for "gram.y",
and that would be harder to pass through the review process.
On the other hand, small patches would be much easier to be argued
over and checked and then accepted or rejected.

I think this is the only "safe" path to include such changes.

Thus I wish this patch could be applied to current cvs head.

I'm ready to update it if required for some stylistic or whatever reason.
However, I really need to have such a patch so as to be able to go on.

It modifies a lot of lines in a very simple way, but other patches should
be much more narrow after this one, that's the idea...

I don't think it harms the parser code, as it validates for me.
I just hope I did not forget any file.

Thanks in advance,

--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr