Fix SchemaManagerFunctionalTestCase::testSwitchPrimaryKeyOrder()

[morozov]

The original test was reworked in #5714 (3.5.x). Prior to the rework, the final assertion would look like this (which was correct):

dbal/tests/Schema/Platforms/MySQLSchemaTest.php

Lines 38 to 44 in 35741d6

	self::assertEquals(
	[
	'DROP INDEX `primary` ON test',
	'ALTER TABLE test ADD PRIMARY KEY (bar_id, foo_id)',
	],
	$sql,
	);

After the rework, the assertion started looking like this (incorrect, note the column order):

dbal/tests/Functional/Schema/SchemaManagerFunctionalTestCase.php

Line 1774 in a4a9b17

self::assertSame(['foo_id', 'bar_id'], $primaryKey->getColumns());

The version of the test after the rework produces the $diff but doesn't use it for anything (it's an unused variable). The diff was supposed to be applied to the database schema, and then the assertion should have been made that the new column order is now effective.

Skipping the test

The test passes on MySQL and SQLite because the corresponding DBALs APIs were designed after MySQL. Specifically, DROP INDEX PRIMARY on MySQL (and, for some reason, on SQLite) drops the primary key. The Postgres implementation gets away with a hack – instead of dropping the index, it generates the PK name and drops the constraint:

dbal/src/Platforms/PostgreSQLPlatform.php

Lines 368 to 375 in 369ab24

	if ($name === '"primary"') {
	if (str_ends_with($table, '"')) {
	$constraintName = substr($table, 0, -1) . '_pkey"';
	} else {
	$constraintName = $table . '_pkey';
	}
	return $this->getDropConstraintSQL($constraintName, $table);

This hack is not implemented for other platforms, so they don't support dropping the PK and fail with a SQL error, which is a bug. This hack cannot be ported to the other platforms easily, because the auto-generated name there is less predictable. This issue could be addressed by replacing the "primary index" with PrimaryKeyConstraint, which, once introspected from the database, would hold the actual constraint name.