Re: [WIP] plpgsql is not translate-aware

Alvaro Herrera <alvherre(at)commandprompt(dot)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