On 26/12/10 18:17, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Dec 26, 2010 at 8:03 AM, Jan Urbański <wulczer@wulczer.org> wrote:
>>> See
>>> https://github.com/wulczer/postgres/commit/44fc42b7708f23483156e4e0e1e321e68b2a7e2d#diff-0
>>> for something that maybe could be used as a basis to autogenerate
>>> errcodes.sgml and plerrcodes.h.
>
>> Interesting. It looks like this might be even easier with perl.
>
> The reason those files aren't autogenerated already is that at the time,
> we had a policy of not requiring perl during a build. Now that that
> restriction has gone down the drain, it might be worth thinking about.
I took a crack at doing that for PL/Python and came up with this piece
of Perl:
https://github.com/wulczer/postgres/blob/616d08178519b61ab5446aa63277e9d7e4841d60/src/pl/plpython/generate-spiexceptions.pl
I then tried to do the same for plerrcodes.h, but found discrepancies.
For instance:
* errcodes.h defines ERRCODE_L_E_INVALID_SPECIFICATION and plerrcodes.h
has "invalid_locator_specification".
* ERRCODE_INVALID_ARGUMENT_FOR_LOG becomes "invalid_argument_for_logarithm"
* ERRCODE_S_R_E_FUNCTION_EXECUTED_NO_RETURN_STATEMENT is
"function_executed_no_return_statement"
* ... and quite some more like this
Additionally, there's one error missing from plerrcodes.h -
ERRCODE_NONSTANDARD_USE_OF_ESCAPE_CHARACTER does not appear there.
Should we a) forget about autogenerating plerrcodes.h and errcodes.sgml
or b) hardcode some exceptions in the Perl script? Changing condition
names would be a big backwards-compat no-no, I presume.
Cheers,
Jan