[DB-SIG] Next Version
Mon, 31 Jan 2000 16:37:05 +0200
"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
> > - 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
> > - 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?