Re: [WIP] plpgsql is not translate-aware - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [WIP] plpgsql is not translate-aware
Date
Msg-id 20081008203127.GF4164@alvh.no-ip.org
Whole thread Raw
In response to Re: plpgsql is not translate-aware  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [WIP] plpgsql is not translate-aware
Re: [WIP] plpgsql is not translate-aware
List pgsql-hackers
Tom Lane wrote:

> It seems like something like that could work.  I'd be inclined to change
> the ereport() macro itself, not errmsg/errdetail/etc.  The domain name
> could be passed in at ereport and then used when evaluating the
> messages.

This seems to work fine.  Modules would provide their message domain by
overriding the ereport() definition to pass a different domain to
ereport_domain(), like the attached plpgsql_i18n.h.

Now, the obvious big problem I have with this patch is that I have to
pass plpgsql's locale path to bindtextdomain(), but I'm not seeing any
decent way to do that ... ideas?

Note that I didn't bother changing the elog() macros to provide a
message domain ... I'm sure that can be fixed but it's very low
priority, given that most of the time those messages do not get
translated.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows
Next
From: Tom Lane
Date:
Subject: Re: [WIP] plpgsql is not translate-aware