hint infrastructure setup (v1) - Mailing list pgsql-patches

From Fabien COELHO
Subject hint infrastructure setup (v1)
Date
Msg-id Pine.LNX.4.58.0403151607510.12777@sablons.cri.ensmp.fr
Whole thread Raw
List pgsql-patches
Dear patchers,

Please find attached my first patch 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.

The current status is that 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.

Thanks in advance,

--
Fabien Coelho - coelho@cri.ensmp.fr

Attachment

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: costly foreign key ri checks (4)
Next
From: Bruce Momjian
Date:
Subject: Improvement to random regression test