Re: [WIP] plpgsql is not translate-aware

Alvaro Herrera <alvherre@commandprompt.com> writes:
> 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?

Shouldn't it just use the same locale path as the backend?  Or are you
stuck getting hold of my_exec_path so you can call get_locale_path?
If the latter, it would probably be reasonable for postmaster/backend
startup to expose the exec path as a global variable.

Two minor nits about the patch itself: the domain field of ErrorData
should be const char * (it's like funcname, not like message; in fact,
this coding ought to be giving you a warning about casting away const)
and there seems some gratuitous inconsistency between the ordering of
function arguments, field locations, and statements copying one to the
other.  (Yeah, I know, that last is *really* anal-retentive, but it's
just easier to see that things match up and you didn't miss anything
when you keep consistent ordering.)

> 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.

None of the time do elog messages get translated, so yes, that would
be pointless.  However ---

> !     if (!errstart(elevel, edata->filename, edata->lineno, NULL, edata->funcname))

--- this looks like it could result in passing a NULL to dgettext,
somewhere along the line.  Probably safer to pass "postgres".
        regards, tom lane