Case sensitivity for role names

[bugsbunny]

Just downloaded PT3 and trying to install it:

OS: Debian Lenny+sid (Linux)
Wine: version 0.9.54

Postgres already installed under Linux. Version 8.2.6 (8.3 upgrade should be any day now, just waiting for it to get out of unstable).

Downloaded the program and ran the installer. No changes made to Wine config yet. Installer ran fine to start.

Got to: Configure PostgreSQL Database

changed username to an existing superuser name with the format: "Abcde" (note the initial cap)

clicked on create

[codedv3]Unable to create PostgreSQL database: PT3 Beta DB1
Reason: Unable to execute query: CREATE DATABASE "PT3 Beta DB1" WITH TEMPLATE = template0 ENCODING = 'SQL_ASCII'; ALTER DATABASE "PT3 Beta DB1" OWNER TO Abcde;; Reason: Fatal Error (ERROR: role "abcde" does not exist )
[/codedv3]

Role Abcde most definitely does exist (I just logged in under it to verify). Role abcde does not.

Also - why are you using SQL ASCII encoding? Defaults are UTF8 and I'd strongly suggest sticking with that. UTF8 being a superset of ASCII you won't lose anything by it, but would gain additional flexibilty (which is never a bad thing - especially when it doesn't cost anything)

[bugsbunny]

OK - I got around this by manually creating the DB using the schema. The solution to the error is to enclose the name in "double quotes".

[bugsbunny]

Just a note that this problem still exists in beta 4.

[APerfect10]

[quotexzv]UTF8 being a superset of ASCII you won't lose anything by it, but would gain additional flexibilty (which is never a bad thing - especially when it doesn't cost anything)[/quotexzv]

Sorry, I somehow overlooked your thread...

UTF-8 encoding is a lot slower in PostgreSQL than SQL_ASCII. We may need to eventually convert to UTF8; however, at this time I think it is the best encoding to use, especially considering we can switch to UTF8 at anytime very easily

Best regards,

Derek

[bugsbunny]

[quote="APerfect10"qku][quoteqku]UTF8 being a superset of ASCII you won't lose anything by it, but would gain additional flexibilty (which is never a bad thing - especially when it doesn't cost anything)[/quoteqku]

Sorry, I somehow overlooked your thread...

UTF-8 encoding is a lot slower in PostgreSQL than SQL_ASCII. We may need to eventually convert to UTF8; however, at this time I think it is the best encoding to use, especially considering we can switch to UTF8 at anytime very easily

Best regards,

Derek[/quoteqku]

Not that important , this thread was more about the case-sensitivity issue - but

Choosing a locale other than C or Posix will have performance implications (and can only be done at initdb), but if the data stored is actually all ASCII then there's no difference (AFAIK) between UTF8 and SQL_ASCII. I'd be curious about seeing any indications or references that this isn't true.

[APerfect10]

[quote="bugsbunny"q1m]Just a note that this problem still exists in beta 4.[/quoteq1m]

I do not understand the case sensitivity problem. We use the exact same case that the user enters. It would be impossible for us to change the case unless if we lower cased everything from the beginning but why would we want to do that?

Best regards,

Derek

[_dave_]

IIRC postgres will (lowercase) or whatever itself if username is not quoted.

So just quote "databaseowner" = problem solved, no?

[APerfect10]

[quote="_dave_"xbx]IIRC postgres will (lowercase) or whatever itself if username is not quoted.

So just quote "databaseowner" = problem solved, no?[/quotexbx]

Gotcha. I have added it to our bug tracker to be fixed

Best regards,

Derek

[APerfect10]

[quote="bugsbunny"mjz]Not that important , this thread was more about the case-sensitivity issue - but

Choosing a locale other than C or Posix will have performance implications (and can only be done at initdb), but if the data stored is actually all ASCII then there's no difference (AFAIK) between UTF8 and SQL_ASCII. I'd be curious about seeing any indications or references that this isn't true.[/quotemjz]

SQL_ASCII is faster because it basically inserts the raw text straight into the database without doing any checking/conversion.

Best regards,

Derek