Re: SCHEMAS and procedures,...

[Vivien Malerba <malerba linuxbox com>]

On mer, 23 fév 2000, Rodrigo Moya wrote:
> > On Tue, 22 Feb 2000 19:05:47 Vivien Malerba wrote:
> > > Under Postgres, each object has a unique OID (object id), so the procs
> > have
> > > each their id. But how can the client know that oid since it is not
> > > returned by
> > > the SCHEMA_PROCS schema, or we introduce another colun in SCHEMA_PROCS
> > > which
> > > gives that OID, or other under other RDBMS (which would be the cleanest
> > way
> > > to
> > > deal with multiple functions with the same name, along with an optionnal
> > > constraint to specify this id)?
> > >
> > > What do you think?
> >
> > fine - and let the provider say, if he provides this
> > object-identification
> > or not via supports() - > the client has to know, if he has to constrain
> >
> > by name or if he can use the oid.
> >
> 
> GDA_Connection_FEATURE_OBJECT_ID?
> 

Ok. Please add it.

I've modified the postgres provider to have it return good values for
SCHEMA_PROC_PARAMS.

Here is the current implementation:
SCHEMA_PROCS:
accepts the constraints OBJECT_NAME, OBJECT_SCHEMA, EXTRA_INFO
returns: (proc name, object id, comments) if no EXTRA_INFO and (proc name,
object id, owner, comments, number of args, SQL def) if EXTRA_INFO.

SCHEMA_PROC_PARAMS:
NEED the constraint OBJECT_NAME with the -->object id<-- (and not the proc
name, because supports(GDA_Connection_FEATURE_OBJECT_ID) will return TRUE;
returns: (in/out/inout, type) for all the parameters, in the order in which
they must be given to the function.

Do we all agree on this for the next release?

As for the aggregates, do we agree to use another SCHEMA (like SCHEMA_AGGS)?

Cheers