Bug 1156114 - engine-setup fails using a mixed case DB name
Summary: engine-setup fails using a mixed case DB name
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Setup.Engine
Version: ---
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Yedidyah Bar David
QA Contact: Pavel Stehlik
URL:
Whiteboard:
Depends On:
Blocks: 1134444
TreeView+ depends on / blocked
 
Reported: 2014-10-23 15:13 UTC by Simone Tiraboschi
Modified: 2022-02-25 08:15 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-06-18 07:12:51 UTC
oVirt Team: Integration
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-36186 0 None None None 2022-02-25 08:15:22 UTC
oVirt gerrit 34444 0 master ABANDONED packaging: setup: ignoring case on DB and DB USER names Never

Description Simone Tiraboschi 2014-10-23 15:13:31 UTC
Description of problem:
engine-setup fails with
 [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to execute
if we try to setup using a mixed case DB name.

Version-Release number of selected component (if applicable):
oVirt 3.5.0

How reproducible:
100%

Steps to Reproduce:
1. launch engine-setup using an answer file with this line OVESETUP_DB/database=str:enginE
2.
3.

Actual results:
it fails with
 [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to execute
if we try to setup using a mixed case DB name.

Expected results:
it completes sucessfully

Additional info:

Comment 1 Sandro Bonazzola 2014-10-23 15:15:45 UTC
Eli, can you take a look too?

Comment 2 Eli Mesika 2014-10-26 08:53:04 UTC
(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...

Comment 3 Simone Tiraboschi 2014-10-27 09:16:03 UTC
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.

Comment 4 Yedidyah Bar David 2014-10-27 09:28:54 UTC
(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.

Comment 5 Simone Tiraboschi 2014-10-27 09:36:58 UTC
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.

Comment 6 Eli Mesika 2014-10-27 10:16:20 UTC
I also prefer suggestion a. from comment 3

Comment 7 Alon Bar-Lev 2014-10-27 10:21:19 UTC
(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.

Comment 8 Simone Tiraboschi 2014-10-28 17:39:00 UTC
(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.

Comment 9 Alon Bar-Lev 2014-10-28 18:32:40 UTC
(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.

Comment 10 Red Hat Bugzilla Rules Engine 2015-10-19 10:52:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.