[DB-SIG] Next Version

[alexander smishlajev]

"M.-A. Lemburg" wrote:
> 
> > - list of available (configured) data sources.
> 
> This can only be done for database manager, e.g. the ODBC
> managers in Windows, iODBC and unixODBC. mxODBC will have
> support for this in a future version.

such information is avalable at least for Oracle connections.  for
PostgreSQL, a list of host databases may be obtained after successfull
connection.

> > - list of database users: logon name, groups/roles
> > - list of user groups (roles): name, members
> 
> Don't know where you would get these infos... you normally
> have to have admin priviledges to even look at those sys tables.

not always.  as far as i know, this information is by default available
to public on PostgreSQL, MS SQL and Oracle.  of course, db admin may
reconfigure this, but at least a list of groups/roles assigned to
current login usually can be obtained as well as login name itself.

> An abstraction layer could query the sys tables directly, BTW.

yes, it could.  but that would require some knowledge about the
implementation of such things in _each_ database.  isn't it a job for db
driver?

> > - list of database objects: owner (schema), name, type (table,
> > view, alias/synonym, procedure etc.), temporary object flag,
> > server-specific info and maybe permission list?  synonyms must
> > point to corresponding object.
> 
> Don't know how other DBs implement this, but mxODBC has the
> catalog methods for these things.

as far as i know, each server has it's own way to access catalog
information.  again, i think that db driver should know a way of doing
this for handled database.

> > and...  in api spec v2.0 i cannot find anything about writing
> > blobs to database.  am i missing something?
> 
> See the type object section: blobs should be wrapped into
> Binary(string) objects and then passed to the .executeXXX()
> methods as parameter. On output you will see a column type
> equal to the BINARY type object in the cursor description.

i was told that this approach is not working for DCOracle.  at least not
with procedure calls.  perhaps allowed LOB operations should be somehow
reported by a db driver?

best wishes,
alex.