[DB-SIG] need some database API design advice

[M.-A. Lemburg]

Peter Eisentraut wrote:
> I'm looking for some API design advice.
> 
> The PostgreSQL developers are currently considering an extension of the
> PL/Python database access API [0].  This is, for better or worse, a
> lower-level custom Python database access API, but you can build DB-API
> on top of that.
> 
> We have added a few functions that extract metadata such as column names
> and types from a result set object (rv.colnames(), rv.coltypes(); think
> cursor.description).  The question was what to do when there is no
> resulting row set, because the command was a utility command such as
> CREATE TABLE.  Option 1 was that the functions should throw an
> exception, because the request is invalid.  Option 2 was that the
> functions should return None.  (This is what cursor.description is
> specified to do.)  This was objected to because it would require extra
> checking for None.  In addition to that, the question relative to option
> 1 in particular was how to detect whether a result row set exists, to
> avoid the exception-throwing calls.  With option 2 you could check for
> is None, of course.  There is an ongoing discussion [1] about which ones
> of these would be better style.
> 
> So, in terms of code, which one of these is "better"?
> 
> 1a.
> 
> rv = plpy.execute("some SQL command")
> try:
>     output(rv.colnames())
> except SomeException:
>     output("it's a utility command")
> 
> 1b.
> 
> rv = plpy.execute("some SQL command")
> if rv.has_rows():  # some currently nonexisting function to be added
>     output(rv.colnames())
> else:
>     output("it's a utility command")
> 
> 2.
> 
> rv = plpy.execute("some SQL command")
> if rv.colnames() is not None:
>     output(rv.colnames())
> else:
>     output("it's a utility command")

When writing code, you typically know whether you are expecting
a result set or not, so you don't run into such problems often.

That said, calling a function is different than accessing an
attribute. You normally expect a function to raise an exception
in case it cannot process your request (due to a missing
result set). The .fetch...() APIs also raise an exception
if no result is present.

Attribute access does not tend to generate exceptions if the
values cannot be set. They simply revert to a default value
(which is None in case of cursor.description).

> [0] http://www.postgresql.org/docs/devel/static/plpython-database.html
> [1] http://archives.postgresql.org/message-id/CAK6bCay4yrFJD3po_bCke4ukjjsPLkbf+ad07jZiAU3N6cwUiA@mail.gmail.com

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 11 2012)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2012-04-28: PythonCamp 2012, Cologne, Germany              17 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/