Re: [gnome-db] get_schema call - a couple of queries about information returned.

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2003-02-11 at 00:27, Steve Fosdick wrote:
> I'd a like a little clarification please on what some of these are
> supposed to return.
> 
> First, the GDA_CONNECTION_SCHEMA_TYPES category.
> 
> Oracle will accept a large number of type names but maps these all to a
> few fundamental types that it stores in the database and, when you query
> the definition of a table, it will be the Oracle fundamental type for
> each colulm that is returned not what you wrote in the original SQL. 
> Neither set quite matches the set of available GDA types.
> 
> Is the GDA_CONNECTION_SCHEMA_TYPE intended to return every type name the
> database recognsies even if some of them are indistinguishable once
> stored, or is it acceptabe to return the fundamental types that actually
> get stored?
> 
it is acceptable to return only fundamental types, although for the
non-existant-yet UI to create tables, it might be good to have all
available types to the user.

> Is the types list supposed to provide a mapping for all GDA types to
> database types or it it accpetable that some of the GDA types don't
> appear in this list?
> 
just map those you can. There is no need in mapping all GDA types. In
fact, some (GeometricPoint, for instance) are provider-specific
(PostgreSQL in this case), so you can just ignore the ones you don't
know about.

> What GDA type should be used for large objects (BLOBs CLOBs etc)?
> 
we discussed recently a API for blobs, very similar to postgresql's.
It's not in yet, so please hold on a little bit on blob types (you can
use binary if you still want to implement it) until we've got the API,
which would make it very good performance-wise.

> Second, the GDA_CONNECTION_SCHEMA_AGGREGATES category.
> 
> There is only space in the column list for this for one input type and
> one output type which is sufficient to describe aggregate functions
> which are applied to table columns and typically used in 'group by'
> situations like count(*), max, sum etc., i.e. these are calculated
> per-group in a  'group by' or for the whole table in the absense of a
> group by.
> 
> The oracle provide currently includes in it's aggregate list some
> functions which aren't aggregates, they are functions which can be
> applied to a column but can also be applied to any expression - these
> may take more than one argument and, if applied to columns, are
> calculated for each row, not for each group in a 'group by' or for the
> whole table.
> 
> Is it safe to say that these functions are misplaced and should be in
> the PROCEDURES category instead (or indeed somewhere else)?
> 
hmm, if they are aggregates (like TO_DATE, etc), I think they should be
in AGGREGATES schema. Probably we want to change the AGGREGATES schema
to return a list (maybe a GDA_VALUE_TYPE_LIST?) of all the types for
arguments.

> Are the type names specified in the AGGREGATES category strings and are
> they supposed to be drawn from the same set as returned by the TYPES
> category?
> 
postgres provider returns the postgres type name. I guess this is ok,
provided that we add a get_gda_type method on providers, so that we can
easily convert from the types returned by the DBMS to GDA types.

How does this sound?

cheers