Re: The job of a relational DBMS

From: Shakespeare <>
Date: Tue, 01 Dec 2009 20:48:33 +0100
Message-ID: <4b157311$0$22918$>

joel garry schreef:
> On Nov 30, 8:35 pm, Gene Wirchenko <> wrote:
>> On Tue, 01 Dec 2009 13:45:44 +1100, Ben Finney
>> <> wrote:
>>> Gene Wirchenko <> writes:
>>>> On Tue, 01 Dec 2009 08:50:34 +1100, Ben Finney
>>>> <> wrote:
>>>>> joel garry <> writes:
>>>> [snip]
>>>>>> Can't a function be part of the DBMS?
>>>>> A non-relational function shouldn't be part of a relational DBMS, no.
>>> This was far too broad, I now see. Originally it was in the context of a
>>> *query* returning a non-relational result, which is really as far as I
>>> should have taken it.
>>      I think you still have problems with the division.  (I do not
>> claim to be able to define the split myself.  I know how difficult it
>> can be to rigourously define something.)

> And perhaps relvars can torture non-relations to relations. But this
> is all too deep for me. I mostly agree with you guys. There should
> be clear delineations between relational and non-relational parts of
> systems, as well as standard SQL versus extensions and procedurals.
>>>>      Addition of integral values is a function mapping two integral
>>>> values to an integral value.
>>> Right; of course, there are heaps of functions operating on attribute
>>> values that can be used *within* relational operations to modify the
>>> relation that will be returned. Such functions definitely belong as part
>>> of the relational DBMS.
>>> What I was trying to express was that relational operations — like the
>>> various relational operations that ‘SELECT’ implements — should only
>>> return data as relations (they might also return status responses). They
>>> should never return non-relation data.
>>      A relation does not have order.  This would not be a relation
>>           select clicode,cliname from clients order by clicode
>> because of the order by clause.

I thought that one was about the order of attributes, not rows.

>>      Having to go through a sort stage when the DBMS might well have
>> been able to easily handle it would be counterproductive.
>>      For example, a group by in SQL forces the result to be sorted by
>> the grouping unless otherwise overridden.

> This is certainly wrong in Oracle, and ought to be wrong everywhere
> else. I don't say that as an Oracle wonk, but rather because ordering
> needs to be explicit by definition.
> jg
> --
> is bogus.

Shakespeare Received on Tue Dec 01 2009 - 13:48:33 CST

Original text of this message