Support named PKs

[billschaller]

Named PK constraints is a pretty universally supported thing. I think DBAL 3 should support naming a PK. This would make interop a little easier on shared environments.

See #807

[deeky666]

@zeroedin-bill you said it would probably be supported on every RDBMS. How would that look like in MySQL. PKs have to be named there PRIMARY, no chance to change that. Also I still don't quite get the purpose of having named primary keys. A PK is a PK and there can only be one so what does naming offer you here?
I am not against supporting it, just wondering about benefits except nice to have.

[deeky666]

Also this most probably affects most of the subsystems. So adding labels accordingly.

[billschaller]

@deeky666 Gah! I missed mysql :(

The benefit is for interop / playing nice with others - if a dev needs to modify an externally maintained system, they can modify their models and send generated DDL to the admin for the system. Sometimes rarely PKs need to get dropped and recreated in the process. DBAL would drop the named PK, and then recreate it with a gibberish name.

Really, it is indeed a 'nice to have' thing. On MySQL, since PKs can't have names, it wouldn't really matter anyway.

[paulodfreitas]

I'm currently running into the same problem. I use the Schema Manager to write migrations using diff to generating up and down scripts. Before it started we follow a internal pattern for naming constraints, pk included, but we can't do this with currently schema implementation.
May see a pointless feature, but for those who have a previous pattern for naming primary keys it's a missing feature.

[paulodfreitas]

Hi,
I started to write code to support named primary keys. While searching which RDBMS support it, I see that everyone in the list of supported platforms allow the use to wrote create table with named PK, still some, e.g. MySQL, ignore it.
So, could a implementation for named PK always create a CREATE SQL with name in primary keys?