Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> The SQL keywords table in the documentation had until now been generated
> by me every year by some ad hoc scripting outside the source tree once
> for each major release. This patch changes it to an automated process.
Didn't test this, but +1 for the concept.
Would it make more sense to have just one source file per SQL standard
version, and distinguish the keyword types by labels within the file?
The extreme version of that would be to format the standards-info files
just like parser/kwlist.h, which perhaps would even save a bit of
parsing code in the Perl script. I don't insist you have to go that
far, but lists of keywords-and-categories seem to make sense.
The thing in the back of my mind here is that at some point the SQL
standard might have more than two keyword categories. What you've got
here would take some effort to handle that, whereas it'd be an entirely
trivial data change in the scheme I'm thinking of.
A policy issue, independent of this mechanism, is how many different
SQL spec versions we want to show in the table. HEAD currently shows just
three (2011, 2008, SQL92), and it doesn't look to me like the table can
accommodate more than one or at most two more columns without getting
too wide for most output formats. We could buy back some space by making
the "cannot be X" annotations for PG keywords more compact, but I fear
that'd still not be enough for the seven spec versions you propose to
show in this patch. (And, presumably, the committee's not done.)
Can we pick a different table layout?
regards, tom lane
