Re: [BUGS] BUG #6452: psql: can't change client encoding from the command line
On 11.02.2012 20:02, felix.gerzag...@gmail.com wrote: Using the command line, I can't change the client encoding, but I can change it using the \encoding command : C:\psql --variable=ENCODING=UTF8 could not find a psql to execute could not find a psql to execute psql (9.1.2) WARNING: Console code page (850) differs from Windows code page (1252) 8-bit characters might not work correctly. See psql reference page Notes for Windows users for details. Type help for help. postgres=# \encoding WIN1252 postgres=# \echo :ENCODING WIN1252 postgres=# \encoding UTF8 postgres=# \encoding UTF8 postgres=# \echo :ENCODING UTF8 postgres=# \q Yeah, \set ENCODING UTF8 doesn't seem to work either. The ENCODING psql variable tracks changes to the server's client_encoding setting, but not vice versa. That probably should be fixed, or at least it should throw an error telling the user to use \encoding instead. As a workaround, you can set the PGCLIENTENCODING environment variable before launching psql. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6457: Regexp not processing word (with special characters on ends) correctly (UTF-8)
The following bug has been logged on the website: Bug reference: 6457 Logged by: Albert Cieszkowski Email address: albert.cieszkow...@cc.com.pl PostgreSQL version: 9.0.6 Operating system: CentOS 5.x Description: OS, base and client encoding UTF-8: peimp= select 'Świnoujście' ~* '\mŚwinoujście\M'; ?column? -- f (1 row) peimp= select 'Świnoujście' ~* '\AŚwinoujście\Z'; ?column? -- t (1 row) but: peimp= select 'Mróz' ~* '\mmróZ\M'; ?column? -- t (1 row) peimp= select 'Mróz' ~* '\AmróZ\Z'; ?column? -- t (1 row) I believe it is connected with bug #5766 and #3433. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6457: Regexp not processing word (with special characters on ends) correctly (UTF-8)
albert.cieszkow...@cc.com.pl writes: OS, base and client encoding UTF-8: What's your lc_collate/lc_ctype settings? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6457: Regexp not processing word (with special characters on ends) correctly (UTF-8)
Hello Tom, Every lc_x value is pl_PL.UTF8 (corresponding to the word's language). Database was created with --locale=pl_PL.UTF8. OS (CentOS 5.x) uses: en_US.UTF-8 Best regards, Albert Cieszkowski W dniu 2012-02-14 16:27, Tom Lane pisze: albert.cieszkow...@cc.com.pl writes: OS, base and client encoding UTF-8: What's your lc_collate/lc_ctype settings? regards, tom lane
[BUGS] BUG #6458: LIKE different to =
The following bug has been logged on the website: Bug reference: 6458 Logged by: Hajo Email address: hlem...@web.de PostgreSQL version: 9.1.2 Operating system: Windows XP Description: colname = 'value' returns true but colname LIKE 'value' returns false. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6458: LIKE different to =
hlem...@web.de wrote: colname = 'value' returns true but colname LIKE 'value' returns false. Is the colname of type char(n) or does it contain trailing spaces? -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6457: Regexp not processing word (with special characters on ends) correctly (UTF-8)
albert.cieszkow...@cc.com.pl writes: peimp= select 'ÅwinoujÅcie' ~* '\mÅwinoujÅcie\M'; ?column? -- f (1 row) Oh, I see the reason for this: the code in cclass() in regc_locale.c doesn't go further up than U+00FF, so no codes above that will be thought to be letters (or members of any other character class). Clearly we need to go further when we are dealing with UTF8. I'm not sure what a sane limit would be though. (It would be nice if there were a more efficient way to get this information than laboriously iterating through all the possible character codes. It doesn't look like we're even trying to cache the results, ick.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6459: logging_collector=off but log_filename set inhibits logoutpu
The following bug has been logged on the website: Bug reference: 6459 Logged by: Christoph Anton Mitterer Email address: cales...@scientia.net PostgreSQL version: 9.1.1 Operating system: All Description: Hi. http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html claims that log_filename is only used when logging_collector is enabled. However it seems that if the later is off, but the former is set (to anything), no log output goes to stderr as well. Cheers, Chris. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6459: logging_collector=off but log_filename set inhibits logoutpu
cales...@scientia.net writes: http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html claims that log_filename is only used when logging_collector is enabled. That is a true statement, as can easily be proven by looking at the source code: nothing except syslogger.c pays any attention to the Log_filename variable. However it seems that if the later is off, but the former is set (to anything), no log output goes to stderr as well. That would depend on other settings that you haven't mentioned, particularly log_destination. Keep in mind also that the active setting of logging_collector can't be changed without a postmaster restart (which is why it's a separate variable from log_destination). regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6412: psql fe-connect truncate passwords
On Sat, Jan 28, 2012 at 7:47 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
On 28-01-2012 18:55, Andy Grimm wrote:
It's not uniform between the client and the server, though.
The server doesn't impose a hard limit for password length and AFAICS it
should not because we aim for backward compatibility.
It sounds like you are suggesting
that rather than increase the limit in the simple_prompt calls, you'd
prefer to decrease the limit read from pwfile? That doesn't
particularly help me.
No, I am not. So there are three concerns here: (i) increase the limit for
simple_prompt() and (ii) raise an error when we reach that limit and (iii) fix
the PasswordFromFile(). Looking at your patch, it seems to fix only (i).
Sorry that it's been a couple of weeks, but I have gotten around to
working on a patch that address more of these concerns. The attached
patch should
1) allow arbitrary length passwords to be read from a file via initdb --pwfile
2) allow the client to accept a password of arbitrary length at the
password prompt
3) allow a password of arbitrary length in a pgpass file
In #2 I say allow the client to accept, because there's a
pq_getmessage call in src/backend/libpq/auth.c which limits the
password message length to 1000 characters. Changing that part of the
code should allow longer passwords, but there may be other lurking
backend issues after that, and I'm not concerned about going beyond
1000 at this point.
--Andy
require understanding of what the real password length limit in a
database is.
There is no such limit; it is stored in a text datatype.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index 99cf5b4..047b25e 100644
--- a/src/bin/initdb/initdb.c
+++ b/src/bin/initdb/initdb.c
@@ -1303,8 +1303,8 @@ get_set_pwd(void)
/*
* Read password from terminal
*/
- pwd1 = simple_prompt(Enter new superuser password: , 100, false);
- pwd2 = simple_prompt(Enter it again: , 100, false);
+ pwd1 = simple_prompt(Enter new superuser password: , MAX_PASSWD, false);
+ pwd2 = simple_prompt(Enter it again: , MAX_PASSWD, false);
if (strcmp(pwd1, pwd2) != 0)
{
fprintf(stderr, _(Passwords didn't match.\n));
@@ -1323,7 +1323,7 @@ get_set_pwd(void)
* for now.
*/
FILE *pwf = fopen(pwfilename, r);
- char pwdbuf[MAXPGPATH];
+ char *pwdbuf = calloc(1,1), buf[1024];
int i;
if (!pwf)
@@ -1332,7 +1332,27 @@ get_set_pwd(void)
progname, pwfilename, strerror(errno));
exit_nicely();
}
- if (!fgets(pwdbuf, sizeof(pwdbuf), pwf))
+
+ do
+ {
+ if (fgets(buf, sizeof(buf), pwf) == NULL)
+break;
+ pwdbuf = realloc( pwdbuf, strlen(pwdbuf)+1+strlen(buf) );
+ if (!pwdbuf)
+ {
+// Out of memory ?
+fprintf(stderr, _(%s: could not read password from file \%s\: %s\n),
+ progname, pwfilename, strerror(errno));
+exit_nicely();
+ }
+ strcat( pwdbuf, buf);
+ i = strlen(pwdbuf);
+ } while (strlen(buf) 0 pwdbuf[i-1] != '\n');
+
+ while (i 0 (pwdbuf[i - 1] == '\r' || pwdbuf[i - 1] == '\n'))
+ pwdbuf[--i] = '\0';
+
+ if (!i)
{
fprintf(stderr, _(%s: could not read password from file \%s\: %s\n),
progname, pwfilename, strerror(errno));
@@ -1340,10 +1360,6 @@ get_set_pwd(void)
}
fclose(pwf);
- i = strlen(pwdbuf);
- while (i 0 (pwdbuf[i - 1] == '\r' || pwdbuf[i - 1] == '\n'))
- pwdbuf[--i] = '\0';
-
pwd1 = xstrdup(pwdbuf);
}
diff --git a/src/bin/pg_dump/pg_backup_db.c b/src/bin/pg_dump/pg_backup_db.c
index 09da892..4f64672 100644
--- a/src/bin/pg_dump/pg_backup_db.c
+++ b/src/bin/pg_dump/pg_backup_db.c
@@ -143,7 +143,7 @@ _connectDB(ArchiveHandle *AH, const char *reqdb, const char *requser)
if (AH-promptPassword == TRI_YES password == NULL)
{
- password = simple_prompt(Password: , 100, false);
+ password = simple_prompt(Password: , MAX_PASSWD, false);
if (password == NULL)
die_horribly(AH, modulename, out of memory\n);
}
@@ -195,7 +195,7 @@ _connectDB(ArchiveHandle *AH, const char *reqdb, const char *requser)
free(password);
if (AH-promptPassword != TRI_NO)
-password = simple_prompt(Password: , 100, false);
+password = simple_prompt(Password: , MAX_PASSWD, false);
else
die_horribly(AH, modulename, connection needs password\n);
@@ -242,7 +242,7 @@ ConnectDatabase(Archive *AHX,
if (prompt_password == TRI_YES password == NULL)
{
- password = simple_prompt(Password: , 100, false);
+ password = simple_prompt(Password: , MAX_PASSWD, false);
if (password == NULL)
die_horribly(AH, modulename, out of memory\n);
}
@@ -288,7 +288,7 @@ ConnectDatabase(Archive *AHX,
prompt_password != TRI_NO)
{
PQfinish(AH-connection);
- password = simple_prompt(Password: , 100, false);
+ password = simple_prompt(Password: , MAX_PASSWD, false);
if (password == NULL)
