[no subject]

SELECT   department,min(salary),max(salary),avg(salary)
FROM     employees;

would be rejected by the database - it doesn't know how many rows to
return.  If the functions applied to the salary column were non-agregate
functions, e.g.:

SELECT   department,to_char(salary, '$99,999')
FROM     employees;

the the query would work correctly:

So, I think we should enhance the API to take account of this.  One
possibility would be to have two separate schema categories, one called
AGGREGATES and the other called FUNCTIONS.  The other possibility would
be to add another column to the existing AGGREGATES category called
Aggregate which is a boolean, true for those functions which are real
aggregates.

Whichever we do, we will need to change the agrument column into a list
as you suggest.

> > 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.

Going back to what I was saying earlier about types, I think there will
be times when we will want to use provider specific types and times when
we will want to use a GDA type, so perhaps should have functions to
convert between the the two as part of the provider API.  Everyone must
understand though that the mapping is not 1:1 and therefore to avoid
unecessary conversions.

What do you think?

Steve.