Re: SQL interface standard

Aaron Watters (aaron@funcity.njit.edu)
Mon, 13 Feb 1995 21:44:33 GMT

In article <199502071937.AA28401@marcel.gamekeeper.bellcore.com> "C. Derek Fields" <derek@gamekeeper.bellcore.com> writes:
>I wrote:
>> 2) a compositional (algebraic/nonSQL) approach that allows queries
>> to be constructed and derived directly in python, either with
>> no visible means of support or using an SQL engine underneith.
>
>Can you make a suggestion? My sense is that this is "interesting" but
>not feasible or practical for the issue at hand.

Maybe unless we aim for...
>
>> 3) some sort of SQL implementation directly in python.
>> If we start with (1) and do it well then we could feed the result
>> directly into (2) which in turn could be used by (3). Viola!
>> Python becomes a killer DB glue language! Interoperability anyone?
>>
>
>Definitely not interesting to me, as a practitioner. My current company
>chose to use Oracle. My next company may use Sybase. I am skeptical that
>there is any value or point, except as an academic exercise, in competing
>with these commercial ventures.

No, let's not compete with them. Let's glue them together. This is a
hot Hot HOT item.

Making various DB's talk to eachother is a very important problem
which is currently solved with expensive and quirky commercial
products or with "chewing gum and bailing wire." It'd be great if
Python could offer a solution in a clean way (even with limitations).
And an "algebraic underpinning" could be clean indeed.

Let's aim high! -a.

[PS: just checking: I have a C-extension "coerce" function
which either fails or always returns it's arguments unchanged.
It must incref both pointed-to objects RIGHT????]
====
There are three kinds of people: those who can count,
and those who can't.
(apropos of incref logic, no?)