Обсуждение: client_lc_messages
So right now we have a single GUC determining the language that log messages are in, and it is PGC_SUSET to avoid a user from sending messages to the log that the DBA cannot read. However, this means that the client cannot get the messages in the language of his choice. What I am wondering right now is whether we could have two separate attributes, one SUSET defining what goes to the log, and another one USERSET defining what's sent to the client. This would require a bit of shuffling, because right now we translate the message pretty early in the call chain -- way before we try to send it to client or server. This would need to be postponed, or alternatively, we would need to store a second, untranslated copy so that another translation can take place later, if necessary. Thoughts? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
2009/10/22 Alvaro Herrera <alvherre@commandprompt.com>: > So right now we have a single GUC determining the language that log > messages are in, and it is PGC_SUSET to avoid a user from sending > messages to the log that the DBA cannot read. > > However, this means that the client cannot get the messages in the > language of his choice. > > What I am wondering right now is whether we could have two separate > attributes, one SUSET defining what goes to the log, and another one > USERSET defining what's sent to the client. > > This would require a bit of shuffling, because right now we translate > the message pretty early in the call chain -- way before we try to send > it to client or server. This would need to be postponed, or > alternatively, we would need to store a second, untranslated copy so > that another translation can take place later, if necessary. > > Thoughts? This would allow me to have the client messages in one language and the log in English, right? If so, +100 or sometihng like that, if it's not too hard to do. Meaning it's not just encoding, but actual translation? -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > 2009/10/22 Alvaro Herrera <alvherre@commandprompt.com>: > > What I am wondering right now is whether we could have two separate > > attributes, one SUSET defining what goes to the log, and another one > > USERSET defining what's sent to the client. > This would allow me to have the client messages in one language and > the log in English, right? If so, +100 or sometihng like that, if it's > not too hard to do. Yes. > Meaning it's not just encoding, but actual translation? Yeah, they would both have to be in server encoding I guess. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On tor, 2009-10-22 at 10:59 -0300, Alvaro Herrera wrote: > What I am wondering right now is whether we could have two separate > attributes, one SUSET defining what goes to the log, and another one > USERSET defining what's sent to the client. Note that only glibc supports switching the language at run time. And doing it is probably very expensive if you want to do it twice per message. I think you could probably get much of the use case out of this if you concentrate on making two switches for the client and the log, which can be set to a language or "untranslated", and if you choose a language it has to be the same for both.
Peter Eisentraut wrote: > Note that only glibc supports switching the language at run time. And > doing it is probably very expensive if you want to do it twice per > message. Ouch :-( > I think you could probably get much of the use case out of this if you > concentrate on making two switches for the client and the log, which can > be set to a language or "untranslated", and if you choose a language it > has to be the same for both. So we'd go with a single setting to define language, which would be the current lc_messages, and two new settings, say translate_log_messages and translate_client_messages, the latter being USERSET. Does that sound reasonable? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera <alvherre@commandprompt.com> writes:
> So we'd go with a single setting to define language, which would be the
> current lc_messages, and two new settings, say translate_log_messages
> and translate_client_messages, the latter being USERSET.
> Does that sound reasonable?
How do we get to the point where individual users can choose their
message language, though? If LC_MESSAGES stays as SUSET then you
haven't really made matters better for anybody.
With the above infrastructure, we could get there if there were a way to
say "LC_MESSAGES is USERSET if translate_log_messages is OFF", but there
isn't and I doubt it would be a good idea to try to make it work like
that.
Maybe we should stick to the original design and just document that
you'll take a big performance hit if the settings are different and
both not "C". And of course make sure we avoid the performance hit
otherwise.
regards, tom lane
2009/10/23 Alvaro Herrera <alvherre@commandprompt.com>: > Peter Eisentraut wrote: > >> Note that only glibc supports switching the language at run time. And >> doing it is probably very expensive if you want to do it twice per >> message. > > Ouch :-( > >> I think you could probably get much of the use case out of this if you >> concentrate on making two switches for the client and the log, which can >> be set to a language or "untranslated", and if you choose a language it >> has to be the same for both. > > So we'd go with a single setting to define language, which would be the > current lc_messages, and two new settings, say translate_log_messages > and translate_client_messages, the latter being USERSET. > > Does that sound reasonable? Does to me. It would certainly cover my use-case, which is that unless your logs are in english, it's really hard to google on anything :-) (I guess it may work for the "big" languages like spanish, french and german, but that's about it. And even then, you're missing out on a lot of resources) -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/