Re: SCHEMAS and procedures,...

[Vivien Malerba <malerba linuxbox com>]

On mar, 07 jui 1998, Rodrigo Moya wrote:
> [Sorry for the date, I'm on the broken machine]
> 
> Vivien Malerba wrote:
> 
> > Hi all!
> >
> > At the moment, the SCHEMA_PROCS does not return the IN(s) and OUT data types.
> > As I understand it, it is supposed to be implemented by another SCHEMA. I
> > would prefer
> > that the SCHEMA_PROCS also return all those data types (it would be easier to
> > code and
> > maybe faster when querying a lot of functions). What's your opinion on this?
> >
> 
> Please decide between Stephan and you, to see what's the best way, but I'd vote,
> as I said before, for a separate schema returning all these parameters:
> 
> param    direction(in,out,inout)    type ....
> 
> This will continue with the current design, one schema to return list of objects
> for one type, and another for describing a specific object.

I was reluctant for this SCHEMA because it means for me to find a way to
deliver to the client information as if it were the result of a query when it
is not: I can't have a query return the in/ou/inout (BTW how do you have INOUT
params?) parameters in postgres, so I need to do more design and code.

> 
> >
> > And is there a SCHEMA for the aggregates (like SUM(), AVG(), ...)? If no, it
> > would be nice
> > to set one up.
> >
> 
> I thought the SCHEMA_PROCS was meant to return this, but if you prefer to have
> two, that is, one for procedures and another one for aggregates. This will mean
> changing the current SCHEMA_PROCS so that they don't return any aggregate
> function.
> 
> Stephan?
> 

I think having a separated schema for the aggregates is a nice thing
since the aggregates use is not the same as functions, and since the client
can't make the difference between the two if not told by the provider. So
setting a new SCHEMA for the aggregates would be a good thing.


I'll do it ASAP.

Cheers 
Vivien