Re: Translatable strings with formatting of 64bit values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Translatable strings with formatting of 64bit values
Date: 2018-04-25 14:08:16
Message-ID: 3969.1524665296@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

librelpIldus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru> writes:
> apparently gettext can't properly identify strings when 64bit values
> formatted with macros like INT64_FORMAT and UINT64_FORMAT. I did
> some research and found out that gettext can work with PRId64 and
> PRIu64. My suggestion is to use these macro for such strings.

I do not believe what you're suggesting can actually work reliably.
In particular it'd fail if we're using our own version of snprintf
and that has different length modifiers than whatever gettext thinks
is the platform standard. Also, how do you think it can possibly work
on platforms lacking the PRId64 macro? gettext would have no better
idea than we do about what to assume that is.

Even if we could trust it to work, it doesn't seem to me that this:

> ereport(ERROR,
> (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
> errmsg("setval: value %s is out of
> bounds for sequence \"%" PRId64 "\" (%" PRId64 "..%" PRId64
> ")", next, RelationGetRelationName(seqrel), minv, maxv)));

is really any cleaner or easier to read than what we're doing now.

An idea that might be worth considering is to provide a helper function
that converts an int64 to a palloc'd string, so that you could write

errmsg("setval: value %s is out of bounds ...",
int64tostr(next), ...)

If you were executing in a long-lived memory context, this might risk
a memory leak, but we've not had a lot of problems with using other
functions that allocate some memory within ereport calls. In any case
the existing method with a local buffer would work as a fallback
if that were a concern.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-04-25 14:18:37 Re: unused_oids script is broken with bsd sed
Previous Message Merlin Moncure 2018-04-25 14:00:43 Re: Built-in connection pooling