Timo Sirainen wrote:

On Saturday, Aug 30, 2003, at 02:16 Europe/Helsinki, Matthew Reimer wrote:

...

Here's a patch that implements mysql authentication. I started with the pgsql files and tweaked them to use mysql instead. It works for me, but there might be a couple of memory leaks. I'm welcome to suggestions on how to clean it up so it can be committed.

Thank you. I'll look at it more closely later, but it looked fine with a quick look.

It would be nice to be able to use asynchronous database lookups. I'm not sure how easy that is with MySQL, of if it's possible at all. With PostgreSQL it looked annoyingly difficult so I haven't done it yet.

Synchronous calls anyway mean that there's only one SQL statement executing at a time and that may slow down the authentication if there's a _lot_ of users logging in constantly. If that's a problem, growing auth_count should help at least some. It specifies the number of auth processes that respond to the authentication queries.

And some day I'll probably move the sql stuff into separate lib-sql and have only a single sql authenticator..

I'm not sure what you mean by asynchronous database lookups. Do you mean you'd like to be able to fire off a db lookup and then come back later to get the results? Like blocking vs non-blocking? I've pasted what may be relevant mysql documentation below in case it might help answer the question.

N db handles could be allocated, giving us N simultaneous lookups.

Matt

From http://www.mysql.com/doc/en/C_API_function_overview.html:

There are two ways for a client to process result sets. One way is to retrieve the entire result set all at once by calling mysql_store_result(). This function acquires from the server all the rows returned by the query and stores them in the client. The second way is for the client to initiate a row-by-row result set retrieval by calling mysql_use_result(). This function initialises the retrieval, but does not actually get any rows from the server.

In both cases, you access rows by calling mysql_fetch_row(). With mysql_store_result(), mysql_fetch_row() accesses rows that have already been fetched from the server. With mysql_use_result(), mysql_fetch_row() actually retrieves the row from the server. Information about the size of the data in each row is available by calling mysql_fetch_lengths().

After you are done with a result set, call mysql_free_result() to free the memory used for it.

The two retrieval mechanisms are complementary. Client programs should choose the approach that is most appropriate for their requirements. In practice, clients tend to use mysql_store_result() more commonly.

An advantage of mysql_store_result() is that because the rows have all been fetched to the client, you not only can access rows sequentially, you can move back and forth in the result set using mysql_data_seek() or mysql_row_seek() to change the current row position within the result set. You can also find out how many rows there are by calling mysql_num_rows(). On the other hand, the memory requirements for mysql_store_result() may be very high for large result sets and you are more likely to encounter out-of-memory conditions.

An advantage of mysql_use_result() is that the client requires less memory for the result set because it maintains only one row at a time (and because there is less allocation overhead, mysql_use_result() can be faster). Disadvantages are that you must process each row quickly to avoid tying up the server, you don't have random access to rows within the result set (you can only access rows sequentially), and you don't know how many rows are in the result set until you have retrieved them all. Furthermore, you must retrieve all the rows even if you determine in mid-retrieval that you've found the information you were looking for.

--- end