At 8:06 -0700 8/12/04, V. M. Brasseur wrote:
Paul DuBois wrote:
At 13:03 -0700 8/11/04, V. M. Brasseur wrote:
Assuming a my.cnf file which looks like this: [client] port=3306 socket=/path/to/mysql.sock [app] user=appuser password=apppwd host=my.host.com
Ignore for now the insecurity of putting a password in the my.cnf file. This is mostly a hypothetical question at the moment.
Calling mysql_options(MYSQL, MYSQL_READ_DEFAULT_FILE, "/path/to/my.cnf"); and mysql_options(MYSQL, MYSQL_READ_DEFAULT_GROUP, "app"); in the client will read the options in these two groups.
How, if at all, would something like this be useful to mysql_real_connect? From my research it appears that you still need to specify the user, host, pwd and port (assuming TCP/IP connection) when calling mysql_real_connect(), so setting these parms in the my.cnf file does not really help for this scenario. Something (a non-API function, most likely) would still need to parse the file separately and grab the parms for passing to mysql_real_connect().
Is this an accurate assessment?
No. If you pass NULL in the mysql_real_connect() params, the values from the option file(s) are used.
Even for the password param? The mysql_real_connect() write-up in your MySQL book says that a NULL passed for password results in allowing connections only if there is no password in the mysql.user.password column for the current user. Perhaps having the password defined via a mysql_options() call trumps this NULL behavior?
Yes, that's correct.
I take it that you're not finding this to be true?
I can't tell yet, as I haven't gotten the coding done. This was mostly a fact-finding excursion, setting up expectations for when I've finally finished with my changes. Many thanks for the assist. You've cleared up a lot for me.
--V
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
