Can you fix the conflicts here please @pe7er

@pe7er you are editing a very old version of the file afaict

@wilsonge Ok, I will
@brianteeman I was already wondering why + how to resolve the conflicts :-) Thanks!

I've updated my local 4.0-dev and resolved the conflict locally.
But when testing the installation again without my patch for MySQL,
the problem was not there anymore...
Closing this issue....

I've updated my local 4.0-dev and resolved the conflict locally.
But when testing the installation again without my patch for MySQL,
the problem was not there anymore...
Closing this issue....

Are you sure this works, the regex should not allow "-" as database...

@HLeithner
Just tested and hyphen works without this patch indeed.

EDIT: this is weird.

In fact, in the present code initialise method the regular expression is:

		if (in_array($options->db_type, ['mysql', 'mysqli']) && preg_match('#[\\\\\/\.]#', $options->db_name))
		{
			Factory::getApplication()->enqueueMessage(Text::_('INSTL_DATABASE_NAME_MSG_MYSQL'), 'warning');

			return false;
		}

For postgresql it is

		// Validate database name.
		if (in_array($options->db_type, ['pgsql', 'postgresql'], true) && !preg_match('#^[a-zA-Z_][0-9a-zA-Z_$]*$#', $options->db_name))
		{
			Factory::getApplication()->enqueueMessage(Text::_('INSTL_DATABASE_NAME_MSG_POSTGRESQL'), 'warning');

			return false;
		}

thx @infograf768 for confirmation.

It does not explain though why the hyphen is not accepted for postgresql but is for mysqli...

because its not allowed in postgressql

https://www.postgresql.org/docs/9.2/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS

SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_). Subsequent characters in an identifier or key word can be letters, underscores, digits (0-9), or dollar signs ($). Note that dollar signs are not allowed in identifiers according to the letter of the SQL standard, so their use might render applications less portable. The SQL standard will not define a key word that contains digits or starts or ends with an underscore, so identifiers of this form are safe against possible conflict with future extensions of the standard.