Re: [WIP] plpgsql is not translate-aware

Tom Lane wrote:
> 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.

That would work too. I'm not sure I prefer this, or the hack to have
dfmgr.c expose it to _PG_init, per my v2 patch.

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

Yeah, I had added it in v2. I had failed to see the warning, but it was
there.

> and there seems some gratuitous inconsistency between the ordering of
> function arguments, field locations, and statements copying one to the
> other.

True, fixed.

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

Hmm, I was trusting that dgettext is documented to accept a NULL as
meaning "use the domain previously set with textdomain", but then it is
possible that elog() will be called before textdomain is set, so you
might be right. Fixed in this new version.

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