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

On Sun, Jan 30, 2011 at 5:23 PM, Jan Urbański <wulczer(at)wulczer(dot)org> wrote:
> On 30/01/11 23:08, Robert Haas wrote:
>> On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański <wulczer(at)wulczer(dot)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(at)wulczer(dot)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

OK. If there's a reason for doing it this way, I'm OK with it.

I'll mark this one Ready for Committer.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company