On Thu, Aug 25, 2016 at 1:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> It's probably best to try >> to hack things somehow so that the worker localizes nothing and the >> leader localizes everything. > > No way that's gonna work. For example, the expected report in > English for the example above is > ERROR: invalid input syntax for integer: "BAAAAA" > That doesn't match anything in gettext's database, because we > already substituted something for the %s. Basically, localization > always has to happen before error message construction, not later.
Oh, right. >> Or we could add another field to the >> message the worker sends that includes the error level as an integer. > > The two alternatives that seem reasonable to me after a bit of reflection > are: > > 1. Hack elog.c to not localize the severity field when in a worker > process. (It'd still have to localize all the other fields, because > of the %s problem.) This would be a very localized fix, but it still > seems mighty ugly. > > 2. Add another field to error messages, which would be a never-localized > copy of the severity string. This might be the best long-run solution, > especially if Jakob can present a convincing argument why clients might > want it. We would be taking some small chance of breaking existing > clients, but if it only happens in a new major release (ie 9.6) then > that doesn't seem like a problem. And anyway the protocol spec has > always counseled clients to be prepared to ignore unrecognized fields > in an error message. > > We could do a variant 2a in which we invent an additional field but > only allow workers to send it, which is more or less the same as your > idea (though I'd still prefer string to integer). I don't find that > very attractive though. If we're going to hack elog.c to have different > sending behavior in a worker, we might as well do #1. I don't have strong feelings about this. Technically, this issue affects 9.5 also, because pqmq.c was introduced in that release. I don't think we want to add another error field in a released branch. However, since there's no parallel query in 9.5, only people who are accessing that functionality via extension code would be affected, which might be nobody and certainly isn't a lot of people, so we could just leave this unfixed in 9.5. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
