Re: autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)

On 30/01/11 23:08, Robert Haas wrote:
> On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański <wulczer@wulczer.org> wrote:
>> On 12/01/11 19:57, Jan Urbański wrote:
>>> On 11/01/11 21:21, Jan Urbański wrote:
>>>> On 11/01/11 18:59, Tom Lane wrote:
>>>>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer@wulczer.org> writes:
>>>>>> On 11/01/11 17:11, Tom Lane wrote:
>>>>> Peter would probably be a better person than me to answer that, but I
>>>>> imagine that what you want is similar to what src/backend/Makefile does
>>>>> for parser/gram.h, only applied at the src/ level or maybe even the
>>>>> root.
>>>
>>>> And actually, if I change my rule to read:
>>>>
>>>> $(SUBDIRS:%=all-%-recurse): $(top_builddir)/src/include/utils/errcodes.h
>>>>
>>>> it works. Now whether that's acceptable or not is another thing entirely...
>>>
>>> And so I came up with three patches to make errcodes.h, plerrcodes.h and
>>> errcodes.sgml (respectively) generated files.
>>
>> Darn, forgot about MSVC again. See
>> http://archives.postgresql.org/message-id/4D2DF996.9000100@wulczer.org
>> for details on how this works.
>>
>> Attached are the previous 3 patches and a fourth one that adds MSVC support.
> 
> I think these look good.  I'm not sure there's any value in stripping
> the duplicates out of plerrcodes.h, though, even if they were
> undocumented:

I think that if you don't strip them out, they will get documented (as
the SGML is generated).

For PL/pgSQL nothing horrible will happen, because if you write
EXCEPTION WHEN foo, it will look up the "foo" label and then compare the
exception's SQLSTATE to decide if it should be handled by that block.
But for PL/Python, the process is reverse: the exception object is
looked up by looking at the SQLSTATE and then injected into Python, so
if SQLSTATE 12345 is both foo_error and bar_error, and you write

try:
    buggy()
except FooError:
    handle_it()

you might be out of luck, if BarError is first on the list, as it will
match the SQLSTATE of the error from buggy() and your except clause will
be useless. AFAICS there's no way to do it another way, short of
dropping the idea of having names for specific exceptions, and forcing
the user to do:

try:
    buggy()
except SPIError as e:
    if e.sqlstate == plpy.condition_to_sqlstate("foo_error"):
        handle_it()
    else:
        raise

which is ugly. It would be useful to have a 1-1 mapping between
condition names and SQLSTATE codes.

> I'm attaching a few other proposed adjustments.

Right, forgot about .gitignores.

Cheers,
Jan