[BUGS] BUG #6452: psql: can't change client encoding from the command line
The following bug has been logged on the website: Bug reference: 6452 Logged by: Félix Email address: felix.gerzag...@gmail.com PostgreSQL version: 9.1.2 Operating system: Win XP Pro SP3 Description: Hi, here is the problem: 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] rs.getMetaData.getTableName always return empty string
I've read some discussions before I write this post. I know that "rs.getMetaData.getTableName" always return empty string just because the developers think it should be alias name in the query, not the underlying table name, which is hard to implement, so it's best to leave it blank. And also there is a "PGResultSetMetaData.getBaseTableName()" can be used to get the table name. I understand this, but it make something very hard. Please see my question: http://stackoverflow.com/questions/9247064/play2s-anorm-cant-work-on-postgresql From the implementation of play's anorm framework, we know that most of other jdbc drivers all return the underlying table name in "rs.getMetaData.getTableName". It make the parse of result set of "join" query easily. Since all other drivers have the same action, will postgresql driver do it too? I think return the underlying table name is much more useful than an empty string.
[BUGS] rs.getMetaData.getTableName always return empty string
I've read some discussions before I write this post. I know that "rs.getMetaData.getTableName" always return empty string just because the developers think it should be alias name in the query, not the underlying table name, which is hard to implement, so it's best to leave it blank. And also there is a "PGResultSetMetaData.getBaseTableName()" can be used to get the table name. I understand this, but it make something very hard. Please see my question: http://stackoverflow.com/questions/9247064/play2s-anorm-cant-work-on-postgresql From the implementation of play's anorm framework, we know that most of other jdbc drivers all return the underlying table name in "rs.getMetaData.getTableName". It make the parse of result set of "join" query easily. Since all other drivers have the same action, will postgresql driver do it too? I think return the underlying table name is much more useful than an empty string.
[BUGS] BUG #6454: Latest x64 msi does not recognize admin account
The following bug has been logged on the website: Bug reference: 6454 Logged by: Paul Peterson Email address: the_r...@yahoo.com PostgreSQL version: 9.1.2 Operating system: Windows 7 home Description: Latest x64 msi does not recognize admin account. There is only one account, mine and it appears as though Windows took away the XP admin default account. suggestions? -- 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 #6454: Latest x64 msi does not recognize admin account
Am 13.02.12 00:09, schrieb the_r...@yahoo.com: > The following bug has been logged on the website: > > Bug reference: 6454 > Logged by: Paul Peterson > Email address: the_r...@yahoo.com > PostgreSQL version: 9.1.2 > Operating system: Windows 7 home > Description: > > Latest x64 msi does not recognize admin account. There is only one account, > mine and it appears as though Windows took away the XP admin default > account. suggestions? Windows 7 deactivates the Administrator account by default. Well, it rather hides it. To make it visible, use the follow steps (sorry, they are in german, because I took them out of our ticket/FAQ system): Systemsteuereung System und Sicherheit Verwaltung Computerverwaltung Lokale Benutzer und Gruppen wählen Benutzer wählen mit rechter Maustaste auf Administrator, es erscheint ein Fenster Eigenschaften in diesem Fenster Häckchen bei "Konto ist deaktiviert" entfernen mit ok bestätigen mit rechter Maustaste auf Administrator klicken und im Popup-Menu "Kennwort festlegen" anklicken Warnmeldung taucht auf, auf Fortsetzen klicken Kennwort eingeben und ok klicken, fertig -- 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 #6455: Wrong match of ipsell dict.
The following bug has been logged on the website:
Bug reference: 6455
Logged by: Desmares Vincent
Email address: vincent.desma...@inovia-team.com
PostgreSQL version: 9.1.0
Operating system: Ubuntu
Description:
Hello everyone,
We recently discovered something that could be a "bug" when using the Full
Text Search of Postgres. More precisely the ispell dictionary.
It appears that words composed with the same character (like “a”, “aa”,
“aaa”, ...) trigger all the prefix and suffix rules even if nothing have
been specified in the dictionary.
We got the bug with the word “e” which was associated to the word “deer”.
Here is a short way to reproduce the bug from scratch :
# 1) Create a test.dict with only “e” inside
cat “e” > test.dict
# 2) Create an empty test.stop file
touch test.stop
# 3) Create a test.affix file with rules :
echo -e 'PFX C Y 1\nPFX C 0 de .\n\nSFX R Y 1\nSFX R 0 r e\n' > test.affix
# 4) Execute those requests :
DROP TEXT SEARCH DICTIONARY IF EXISTS testispell CASCADE;
CREATE TEXT SEARCH DICTIONARY testispell (
TEMPLATE = ispell,
DictFile = test,
AffFile = test,
StopWords = test
);
CREATE TEXT SEARCH CONFIGURATION test_ispell (
PARSER = "default"
);
ALTER TEXT SEARCH CONFIGURATION test_ispell ADD MAPPING FOR asciihword WITH
testispell;
ALTER TEXT SEARCH CONFIGURATION test_ispell ADD MAPPING FOR asciiword WITH
testispell;
ALTER TEXT SEARCH CONFIGURATION test_ispell ADD MAPPING FOR uint WITH
testispell;
ALTER TEXT SEARCH CONFIGURATION test_ispell ADD MAPPING FOR word WITH
testispell;
SELECT * from ts_debug('test_ispell', 'deer');
# 5) You should get a table with this result :
alias : "asciiword"
description : "Word, all ASCII"
token : "deer"
dictionaries : "{testispell}"
dictionary : "testispell"
lexemes : "{e}"
It appear that it’s reproductible with more characters of the same letter :
- .dict with [ee] searching for [deeer] give [ee]
but
- .dict with [ee] searching for [eer|deee] give nothing
Did we miss a configuration or a default behavior, or there is really a bug
?
Regards,
Vincent Desmares
Developer @ Inovia-team
--
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 #6456: no password
The following bug has been logged on the website: Bug reference: 6456 Logged by: tmpfs1987 Email address: tm...@hotmail.com PostgreSQL version: 9.0.6 Operating system: windows xp Description: I used the postgreSQL some time ago and it created an account on my windows folder, now I re installed it after downloading a more recente version, but now I can't finish the installation because it asks me about for a superuser password that I don't know where to get, I tried the one from the website registration but doesn't work. thanks for your time -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
