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

Поиск
Список
Период
Сортировка
От Jan Urbański
Тема Re: autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)
Дата
Msg-id 4D45E4EB.3040109@wulczer.org
обсуждение исходный текст
Ответ на Re: autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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:
>>>>> Jan Urbański <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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Review: Fix snapshot taking inconsistencies
Следующее
От: Robert Haas
Дата:
Сообщение: Re: autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)