Hi!
I just wrote a short specification for an extension of the
client/server protocol and wanted to hear if anyone would have any
comments regarding this.
------------
We need to extend the client/server/protocol with the following features:
- Get warnings from the server (for any command).
Two ways to do this:
- Maintain a linked list in the server with warnings for the last command
that can be retrieved with SHOW WARNINGS.
- The client should for each command send to the number of warnings
(like we now send affected rows).
- Send warnings as marked 'warning rows' during execution of the command.
- We should send up to SQL_WARNING_LIMIT rows to the client.
- Add 'progress' packages to the protocol and let the client register a
callback function that will be called for each progress package.
This allows the client to implement a 'progress bar'.
The package should include two numbers: Current record position and
estimated end record position.
This doesn't have high priority, but should be thought of.
- For each column send also the database and real table name (now only the
alias is sent).
The new MYSQL_FIELD structure in 4.0 already have these columns.
- For threaded clients, add an option to specify execution time for the client.
(Should be implemented with thr_alarm and a signal handler thread).
This doesn't have high priority, but should be thought of.
- mysql_prepare(MYSQL *, const char query, uint query_length);
mysql_bind_execute(MYSQL *, uint param_number, MYSQL_BIND *bind)
mysql_execute(MYSQL *);
- In the BIND structure, there should be 'ulong *length' pointer from where
one can retrieve the length for FIELD_VAR_STRINGS columns.
- The interface should automaticly convert the bind data to the column
type that the server wants.
- mysql_bind_for_execute() will fill in the MYSQL_BIND structure with
data about the parameter (like type, max_length...)
- mysql_option(MYSQL *, MYSQL_OPT_BIND_RESULTS);
mysql_bind_result(MYSQL *, uint column_number, MYSQL_BIND *bind)
This should be used by clients that wants to bind the result to variables.
One has to bind all columns in the result.
mysql_fetch_row() will convert data and update the bound variables.
- Remove compatiblity with old 3.21 clients (one should still be able to
configure with -DUSE_OLD_FUNCTIONS to keep the server compatible with these).
- New 'virtual' field type for BIND: FIELD_TYPE_STRING_POINTER.
If this is used, we will update a string pointer to point to where the data
is. Note that if this means that if the data is a packed number,
the mysql_bind..() function has to allocate space to where we should
store the value.
Requirements:
- Old clients >= 3.22.0 should work as before.
- All binary data should be sent with low byte first.
- We should support at least the following 'fast native' types for BIND:
- signed and unsigned integer (1-8 bytes)
- float
- double
- strings
- datetime (Should be sent as packed number)
All other types should be sent as strings
- Keep the interface 'clean'; Better to require the user to specify all
BIND options than have entries that are optional.
(This will make it much easier to write a really fast interface).
- One should implement BIND (prepare and fetch) so that it's easy to
integrate this with the MyODBC driver.
- We should allow bind arguments 'anywhere'; We should return
FIELD_TYPE_VAR_STRING for parameters for which we can deduce a type.
Benefits (of BIND):
- The server doesn't have to convert numbers to strings before sending them
to the client.
- The clients doesn't have to convert numbers to strings or escape strings
when using PREPARE.
Disadvantages:
- Bigger client library.
- A lot of convert functions in the client (double->string ...)
- More things to document and test.
- Need of more examples.
-------------
Regards,
Monty
