Description:
I notice in the documentation you can connect to a URI using the new --uri option. This seems to be of the form:
user:pass@host[:port]/dbname, or
user@::socket/dbname
Which seems fine until you wonder what happens if you want to talk to a socket named 1 or want to use IPv6 and an address such as ::1. Here it looks as if there may be some confusion.
I notice the MySQL GO driver uses a similar URI format, see: https://github.com/go-sql-driver/mysql
Notice that it resolves this problem by using the following uri formats:
user:password@tcp(localhost:5555)/dbname
root:pw@unix(/tmp/mysql.sock)/myDatabase
It also allows "options" to be added , usually used by the driver, such as adding a connect timeout, setting the LOCALE to be used etc etc.
This seems more flexible than what I've seen suggested for this new API (though it's very similar) and perhaps it's also more flexible.
How to repeat:
See above.
Suggested fix:
I may have missed a more formal definition in the MySQL documentation of exactly what values the URI can contain. Section 3.8.2.1 describes this briefly but is very informal.
If there's a better fuller documentation of this please point me to it but also please consider making a URI that's unambiguous, so please consider perhaps adopting the GO driver approach and making the user:pass@::socket obsolete after 5.7 and clearly document this where needed.
I also see a need in this URI format to specify which protocol should be used. It's not clear to me if that can be done in the URI itself, if not please detail an option to allow this as relying on a specific port running a specific protocol may catch people out.
I also notice that if no port is given the mysqlsh tries to connect to port 33060 (new protocol). That's not very clearly defined. Drivers in the future may need to support both protocols and therefore if certain parameters are missing knowing what the expected behaviour is will be important. In go for example you must provide the port to connect to and it's not implied. So clarification here again seems to be important.
© 2025, Oracle Corporation and/or its affiliates