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?
--
Paul DuBois, MySQL Documentation Team
Madison, Wisconsin, USA
MySQL AB, www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
