On Fri, Mar 09, 2001 at 03:48:33PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Well, SQL defines these. Do we want to make our own list? However,
> > numeric codes also have the advantage that some hierarchy is possible.
> > E.g., the "22" in "2200G" is actually the category code "data exception".
> > Personally, I would stick to the SQL codes but make some readable macro
> > name for backend internal use.
>
> We will probably find cases where we need codes not defined by SQL
> (since we have non-SQL features). If there is room to invent our
> own codes then I have no objection to this.
>
> >> I am not sure we can/should use gettext (possible license problems?),
>
> > Gettext is an open standard, invented at Sun IIRC. There is also an
> > independent implementation for BSDs in the works. On GNU/Linux system
> > it's in the C library. I don't see any license problems that way.
>
> Unless that BSD implementation is ready to go, I think we'd be talking
> about relying on GPL'd (not LGPL'd) code for an essential component of
> the system functionality. Given RMS' recent antics I am much less
> comfortable with that than I might once have been.
cf. http://citrus.bsdclub.org/
and the libintl in NetBSD, at least NetBSD-current, works. The hard part
was eg convincing gmake's configure to use it as there are bits like
#if __USE_GNU_GETTEXT
rather than just checking for the existence of the functions (as well as
the internal symbol _nl_msg_cat_cntr).
So yes it's ready to go, but please don't use the same m4 in configure.in as
for GNU gettext.
Cheers,
Patrick