raf raf@comdyn.com.au
Thu, 4 Jun 1998 14:54:54 +1000

M.-A. Lemburg wrote:
>Jim Fulton wrote:
>>M.-A. Lemburg wrote:
>>>M.-A. Lemburg wrote:


>>> callproc([params])
>>>      Note: this method is not well-defined yet.  Call a stored
>>>      database procedure with the given (optional) parameters. Returns
>>>      the result of the stored procedure.
>> How are IN OUT and OUT parameters handled?
>> How common are stored procedures across database products
>> anyway?

>I don't think that there is a lot of portability regarding stored
>procedures. For one, the storing process itself is *very* DB
>dependant (with each database having its own syntax for defining
>procedures) and it is not really clear how to handle the parameters
>(esp. the IN OUT ones you mention).

you don't have to "handle" the parameters. you only have to design an
interface for doing so. how they are handled is left to the compliant
module implementor.

and just because you can't, in general, port stored procedures between
databases (sybase and sql anywhere being the only example i know), that
doesn't mean that the syntax for calling stored procedures needs to change
across compliant modules as well. if someone has to port the stored
procedures, why do they also have to port the (python) calls to them?
surely each compliant module can produce the appropriate db-specific sql

just how different are stored procedures in different databases?
i haven't seen many databases but i can't imagine being surprised
by any of them. they didn't cancel the odbc project because of this :)


>>> nextset()
>>>      If the database supports returning multiple result sets, this
>>>      method will make the cursor skip to the next available set. If
>>>      there are no more sets, the method returns None. Otherwise, it
>>>      returns 1 and subsequent calls to the fetch methods will return
>>>      rows from the next result set. Database interface modules that
>>>      don't support this feature should always return None.
>> This feels a bit cumbersome to me.  What happens if you need
>> to iterate over multiple results simulataneously.  I'd rather
>> see an object for each result set and return a tuple of result
>> sets if there are more than one.

>Sorry, can't really comment on that one, since I have no experience
>with it. Only one thing: introducing too many different new
>types will put a real strain on interface implementors. We should
>avoid that.

what "new types" are you referring to here? i don't understand.
the difference as i see it is getting result sets one at a time,
or in a tuple. surely a tuple isn't going to cause too much strain :)
i agree that using nextset() is too cumbersome. i hope that both
approaches are supported.


>>> A Cursor Object's description attribute returns information about each
>>> of the result columns of a query. The type_code is defined to be equal
>>> to one of five types exported by this module: STRING, RAW, NUMBER,
>>> DATE, or ROWID.
>> There needs to be a distinction between ints and floats.

>IMHO, we should simply use the standard Python types the way
>they are meant: numbers with precision become floats, ones without
>precision become integers. Very long integers (BIGINT) are output
>as longs.

be careful. the ctsybase module retrieves "money" values as float,
not long. since "money" is an 8 byte integer, 4 digits of precision
(typically) are lost this way. i'm sure people have been killed for less :)