On 26/12/10 18:17, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Dec 26, 2010 at 8:03 AM, Jan Urbański <wulc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
