On Sun, Jan 30, 2011 at 5:23 PM, Jan Urbański <wulc...@wulczer.org> wrote: > On 30/01/11 23:08, Robert Haas wrote: >> On Wed, Jan 12, 2011 at 5:10 PM, Jan Urbański <wulc...@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==?= <wulc...@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.9000...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
