[DB-SIG] Getting schemas and other niceties

[Kevin Jacobs]

On Sun, 20 Jul 2003, Fabien COUTANT wrote:
> On Saturday, 19 July 2003, you (Kevin Jacobs) wrote:
> > > - SQL-level representation should be returned (such as the already declared
> > >     type codes used in cursors description attribute) instead of byte
> > This is a dangerously ambiguous statement.  What I _think_ you mean is that
> > you want canonical representations (not SQL representations) instead of
> > RDBMS-native binary values.  What you do not want are SQL literal
> > representations, at least not by default.
> 
> Yes, exactly.  I want types returned as driver.STRING, driver.BINARY,
> driver.NUMBER etc.

This causes tremendous information loss with the current DB-API type
objects.  I _need_ to know if the driver.NUMERIC is an SQL NUMERIC or a
FLOAT, or an INT8 or INT32 or INT64.

> > > - columns in result sets corresponding to features of standard SQL (column
> > >     name, type, size, unique, nullable, ...) should be made first and
> > First and mandatory?  Why enforce an ordinal relationship among attributes
> > of a given column?  The existing description tuple concept is simply
> > outdated and needs to be replaced, not kludged with extensions.
> 
> To be useful there must be a way to find back precise columns (e.g. column
> name).

I'm not suggesting the removal of ordinal addressing of columns -- just the
ordinal relationship between column schema/descritions.  i.e., extending the
existing 7 element tuple is a silly thing to do.  Thus there will still be a
column values 0..n-1 for each tuple, since this is at the heart of the
relational model.  Column names should still be optional, since many RDBMS
will return unpredictable names (or none at all) for many types of
expressions.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs at theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com