Bug 1156114

Eli, can you take a look too?

(In reply to Sandro Bonazzola from comment #1)
> Eli, can you take a look too?

Postgres is not case-sensitive on entity names so if you create a database named enginE actually when you list the databse names you will see that 'engine' was created.

So, any limitation on the db name mixed case should be looked in our scripts ...

I see that there is a fixing patch on that, will look at it as well...

Eli,
unfortunately it's not that easy:

Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case. For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL, but "Foo" and "FOO" are different from these three and each other. (The folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard, which says that unquoted names should be folded to upper case. Thus, foo should be equivalent to "FOO" not "foo" according to the standard. If you want to write portable applications you are advised to always quote a particular name or never quote it.)
ref: http://www.postgresql.org/docs/9.3/static/sql-syntax-lexical.html

And, not enough, currently identifier in pg_hba.conf and other conf files are case Sensitive also if not quoted:
http://www.postgresql.org/message-id/EC867DEF52699D4189B584A14BAA7C21654422EB@blreml504-mbx.china.huawei.com

Now we are using somewhere unquoted identifier and somewhere else quoted ones, than we are writing conf files without any intervention there.
So currently it's not working if the user provides a DB names with uppercase characters.

Now we need to decide if:
a. we want to completely ignore the case on identifier writing them as lowercase string wherever is possible (in that case we are also assuming that we can connect to a manually created DB only if it's name could be treated as case insensitive one) 
b. we want to honor mixed case identifier: in this case we need to ensure that we are going to honor it quoting its name wherever we use it such as in the webapps, on other apps as DWH/reports, on engine-config and on backup/restore tools and so on.

What should we do? personally I'd prefer for solution a.

(In reply to Simone Tiraboschi from comment #3)
> What should we do? personally I'd prefer for solution a.

c. CLOSE WONTFIX...

That is, leaving this bug for reference, but do nothing in practice. If your problem is not that you want to support (a or b, both support) case sensitivity, but merely that you personally spent a long time understanding the problem and would rather save potential users this time,

d. Just emit a suitable error and fail if db/user names are not all lower case.

on my opinion c. it's not an option: current code is failing with

 [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to execute [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to execute

witch is quite an ambiguous error and can cause further confusion.
At least d. lets the user know why it's failing.

I also prefer suggestion a. from comment 3

(In reply to Eli Mesika from comment #6)
> I also prefer suggestion a. from comment 3

why can't we support mixed cases? what is the problem? psql supports that, sooner or later there will be issues.

(In reply to Alon Bar-Lev from comment #7)
> why can't we support mixed cases? what is the problem? psql supports that,
> sooner or later there will be issues.

Yes, technically we can: I don't see any technical issue that prevent us to support mixed case identifier on DB and user names, we need to check all the statement where we use that identifier in every tool in order to ensure we are always quoting them.

On the other side I don't see any real user benefits from mixed case identifiers: on my experience, when I saw DB or table names with mixed case identifier it was always due to a careless act or a mistake causing than strange behaviors.

On my opinion is more user friendly just to rely on case insensitive identifiers.
We can force them being lowercase by an implicit conversion as on suggestion a. from comment #3 or we can simply explicitly reject mixed case identifiers with an error as on suggestion d. from comment #4.
On my opinion, suggestion a. makes it behaving more similar to an SQL statement and so it can be more user friendly for a DBA.

(In reply to Simone Tiraboschi from comment #8)
> (In reply to Alon Bar-Lev from comment #7)
>
> On the other side I don't see any real user benefits from mixed case
> identifiers: on my experience, when I saw DB or table names with mixed case
> identifier it was always due to a careless act or a mistake causing than
> strange behaviors.

there is no other side nor decision to make, sysadmin is in charge of creating the database, we should support every feature postgresql supports.

please fix this properly.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.