Quoting Chris Darroch <[EMAIL PROTECTED]>:
3) Error reporting via a standard set of APR_DBD_* error codes
Switching to APR_DBD_* error codes will *probably* break binary compatibility requirements for 1.x (i.e. int will become apr_status_t, which is probably the same thing, but I'm not sure if we're allowed to assume that). So, this would most likely be a 2.0 thing. Some long term APR folks may have more input on this...
Overall, this seems like a *large* effort to me. Forewarned is forearmed, I guess.
Yes, this is a can of worms of gigantic proportions. We'd need to define a set of error codes that map into *all* underlying error conditions and then return that consistently. Although it's The Right Thing To Do (TM) and we *should* do it, I'm personally not pressed to go that way in a hurry - I can live with the current 0/not-zero situation for a while (read: too lazy to do all that work right now ;-).
4) I've been wondering if we should deprecate and then remove the apr_dbd_escape() function. Because we encourage the use of placeholders, and because we introduce a new special character (%) which we really ought to be escaping as well as the usual ones
Not clear on the escaping of % here. What would be a typical use for escaping of prepared statements?
5) Renaming functions like apr_dbd_get_entry() to apr_dbd_entry_get(). Is this the kind of thing that can be done with a minor version number change, i.e., in 1.3?
I think Garrett already answered this one - only possible when jumping major versions. So, this is something for 2.0.
-- Bojan
