Re: [BUGS] BUG #2632: createuser language poblem
Quoting Tom Lane <[EMAIL PROTECTED]>:
"Massimo Fidanza" <[EMAIL PROTECTED]> writes:
Hi, I discover a very annoying bug in the create user command. I have the
environment variable LANG=it_IT.UTF-8 and when I try to crate a new user wit
the create user command, at he prompt I have the three questions
Shall the new role be a superuser? (y/n)
Shall the new role be allowed to create databases? (y/n)
Shall the new role be allowed to create more new roles? (y/n)
The reason those aren't getting translated is that the Italian
translations have not been updated for 8.1 --- the entries in it.po
still look like the 8.0 wording:
#: createuser.c:170
msgid "Shall the new user be allowed to create databases? (y/n) "
msgstr "Il nuovo utente può creare database? (s/n)"
#: createuser.c:181
msgid "Shall the new user be allowed to create more new users? (y/n) "
msgstr "Il nuovo utente può creare altri utenti? (s/n)"
If this annoys you, please join the PG translation project and help to
fix it:
http://pgtranslation.projects.postgresql.org/
regards, tom lane
Yes, I can join the translation team and translate the missing strigs,
but I think this is not the right answer. I think the best solution is
to accept the english answer too.
I made a patch to common.c (src/bin/scripts/common.c) that compare the
user answer with the translated and the english affermative (y) and
negative (n) answer. I add a case insensitive comparison too.
I know that this can generate conflicts between languages, but looking
at the other languages in wich Postgresql is already translated there
are no conflict between english and non english languages. I look for
other languages too and I find a possible conflict with african
Swahili language, where the answers are (ndiyo==yes/kataa==no), but
they can for example specify (y/n) as (nd/k).
Bye Max!
--- common.c2006-09-19 22:41:35.0 +0200
+++ common.c2006-09-19 22:45:29.0 +0200
@@ -25,2 +25,5 @@
+#ifdef WIN32
+#define strcasecmp(s1,s2) lstrcmpiA((s1), (s2))
+#endif
@@ -208,5 +211,5 @@
{
- if (strcmp(string, _(PG_YESLETTER)) == 0)
+ if ((strcasecmp(string, _(PG_YESLETTER)) == 0) || (strcasecmp(string,
"y") == 0))
return 1;
- else if (strcmp(string, _(PG_NOLETTER)) == 0)
+ else if ((strcasecmp(string, _(PG_NOLETTER)) == 0) ||
(strcasecmp(string, "n") == 0))
return 0;
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2632: createuser language poblem
Massimo Fidanza <[EMAIL PROTECTED]> writes: > Yes, I can join the translation team and translate the missing strigs,=20= > =20 > but I think this is not the right answer. I think the best solution is=20= > =20 > to accept the english answer too. I liked Peter's idea better (ie, not have the y/n in the string-to-be-translated but generate it dynamically using the same strings that will actually be matched to the input). Your approach fails if there are any languages that use y or n in a way conflicting with the English usage ... and whether or not we have any such translations today, who knows what will be out there tomorrow? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1931: ILIKE and LIKE fails on Turkish locale
Victor Snezhko <[EMAIL PROTECTED]> writes: > 2) When I try to create a stored procedure to create table (e.g., for >creating table only if it doesn't already exist), it fails to >compile if i use cyrillic letter "È" (unicode id: 0x0445, utf-8 >representation is D1 85) with the following weird error: > ERROR: expected dot between identifiers: È > CONTEXT: compile of PL/pgSQL function "createoraltertable" near line 2 > the following query fails: > CREATE OR REPLACE FUNCTION TestFunction() > RETURNS int > AS $$ > BEGIN > SELECT È FROM test_table; > RETURN 0; > END; > $$ LANGUAGE plpgsql; I tried to duplicate this without success on Fedora Core 5. Either your ru_RU.utf8 locale works differently from Fedora's, or something else is wrong. Looking at the code, the only very plausible theory is that isspace() is doing something different than we expect it to. I wonder whether you have the database encoding set to something else than what the postmaster's LC_CTYPE locale expects? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #2642: Connection problems without IPv6
The following bug has been logged online: Bug reference: 2642 Logged by: Christoph Zwerschke Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.4 Operating system: Win XP Description:Connection problems without IPv6 Details: I am using PostgreSQL 8.1.4 on Win XP, installed from the official binary. When I start the PostgreSQL service, and I have my LAN network interface activated with TCP/IP installed, but IPv6 deinstalled, I cannot connect to the PostgreSQL database. In the log file, I get the following error message: "LOG: could not receive data from client: An operation was attempted on something that is not a socket." This problem does *not* happen if: - the LAN network interface is deactivated or - the TCP/IP protocol is deactivated or - the TCP/IP protocol is activated, and TCP/IP v6 protocol is installed (must not be activated) It happens only if: - the LAN network interface is activated and - the TCP/IP protocol is activated and - the TCP/IP v6 protocol is not installed If this problem cannot be fixed, it should at least be mentioned in the Windows FAQ (http://pginstaller.projects.postgresql.org/faq/FAQ_windows.html) . ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2642: Connection problems without IPv6
"Christoph Zwerschke" <[EMAIL PROTECTED]> writes: > It happens only if: > - the LAN network interface is activated and > - the TCP/IP protocol is activated and > - the TCP/IP v6 protocol is not installed Perhaps you have a name server that is reporting only an IPv6 address for your machine? Turning off the LAN prevents contacting that server? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2642: Connection problems without IPv6
Tom Lane wrote: > Perhaps you have a name server that is reporting only an IPv6 > address for your machine? Turning off the LAN prevents contacting > that server? No, and I'm using only localhost as address, i.e. I am contacting localhost, and I have listen_addresses = localhost in postgresql.conf. My name server does not resolve internal names (I'm using LMHOSTS). All other programs do work with that configuration (i.e. IPv6 uninstalled). However, I just noticed that when I stop the DNS client (caching) service, then the problem disappears as well. Strange. -- Christoph ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
