Alvaro Herrera <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
