Alex Dubov wrote:

> int apr_dbd_entry_is_null(const apr_dbd_row_t *row, int n)

   That strikes me as a good solution for the current API; thanks!
I suppose it might have to be:

int apr_dbd_entry_is_null(const apr_dbd_driver_t *driver,
                          const apr_dbd_row_t *row, int n);

but I haven't thought about it enough yet to be sure either way.


Bojan Smojver wrote:

> However, we can have a new function instead, so that we remain  
> backward compatible. Someting like apr_dbd_entry_get(). Or, if that's  
> no good because people may expect intuitively that this is the same as  
> apr_dbd_get_entry(), then maybe apr_dbd_binary_get() or something like  
> that.

   Yeah, I'd suggest that any renaming of functions that we do
to match APR/APU (driver_get, dbname_set, row_get, entry_get, name_get?)
should not also add or change the functionality from the old versions.
Otherwise it'll just add confusion for everyone.


Bojan Smojver wrote:

> Quoting Alex Dubov <oakad@yahoo.com>:

>> from here everything works just like with
>> printf - if you push pointer incompatible to
>> specifier, it's most likely a crash.
[snip]
> I think we should stick with a single letter convention, for  
> simplicity of parsing. So, how about:
> 
> - %S - string (i.e. char *, text in SQL)
> - %D - unsigned integer
> - %c - char
> - %C - unsigned char
> - %h - short
> - %H - unsigned short
> - %l - long
> - %L - unsigned long
> - %q - quad (i.e. long long)
> - %Q - unsigned quad
> - %F - double
> - %b - blob (brigade, backend specific blob type 1 in SQL*)
> - %B - blob (brigade, backend specific blob type 2 in SQL*)
> - %o - blob (brigade, backend specific blob type 3 in SQL*)
> - %O - blob (brigade, backend specific blob type 4 in SQL*)
> - %i - time (string, time in SQL)
> - %a - date (string, date in SQL)
> - %A - datetime (string, datetime in SQL)
> - %t - timestamp (string, timestamp in SQL)
> - %T - timestamp with zone (string, timestamp with zone in SQL)

   I confess I'm alarmed and frightened by all this, although I am
still willing to be convinced of its necessity.  At the very least,
I'd hope that most of the processing can occur in set of routines
common to all drivers, otherwise it'll just be terribly difficult to
maintain going forward if each driver implements the parsing for
all this on its own.

   Dealing just with LOB types, I'm also concerned about whether
using just a brigade as input data is possible.  It may also
prove to be difficult to provide a portable interface; from what
little I know about MySQL, it handles LOBs like any other data
type, so a simple brigade might be OK.  Oracle, as I noted, requires
a whole song and dance if you want to insert or update LOB data
into a row as an atomic transaction.  If you want to make Oracle
do that, you really need to pass in the following:

- LOB data
- LOB data length
- table name
- LOB column name

(Although it's sometimes possible to determine the last two from
the SQL query, it's not always so.)

   Anyway, I'll think on the various suggestions for a bit before
making other comments.  And maybe someday I'll actually get back
to writing some code.  :-)

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B