Re: A question for Mr. Celko

From: John Jacob <jingleheimerschmitt_at_hotmail.com>
Date: 19 Jul 2004 11:13:53 -0700
Message-ID: <72f08f6c.0407191013.4828d3b2_at_posting.google.com>


> Nope; in set theory, it is a function that returns one if a predicate
> is true and zero if it is false. Among other things, you use them to
> define a set. You will see them represented by a lower-case delta
> (Rozenthzein), an uppercase Chi or square brackets (Knuth and Iverson)
> in computer science literature. Some characteristic functions can be
> applied to each element of a set in parallel and get an immediate
> result like [MOD(i,2) = 0]. Some require finite computations --
> finding out if node a is the uperior of node b in a adjacency model of
> a tree. Some require an unknown number of computations -- the (3n+1)
> problem. That unknown number of steps might be infinite, so you can
> never determine if some value is in the set or its complement at all,
> even tho you know it must be in one or the other.

Standard mathematics suffers from many of these same problems, yet we do not feel the need to restrict our calculators unnecessarily. SQL and it's pack of deviant dialects deliberately and unnecessarily restrict power in the name of protecting the poor developer from himself.

> >> As for no recursion, self-references, and indeterminable sets, it
> sounds to me like this is just unnecessarily restricting the power of
> the language, a technique extremely common in today's systems, and one
> of the reasons relational languages get such a bad rap. <<
>
> No, the bad rap comes from weak programmers who are having enough
> problems learning even simple relational/set concepts. They write
> crappy code and blame the tool. I don't mean to avoid language design
> issues, but the average commercial programmer cannot handle simple
> procedural recursion.

It is a constant theme in existing products that the developer must be saved from himself, for he will surely write bad queries, and we musn't allow that. To this end, the DBMS vendors relentlessly shackle the implementations with proposed "fixes" to prevent things like accidental recursion and so on. The problem is in doing so they prevent us from doing things that are actually useful! I cite a recent addition to the Microsoft DBMS, cascading updates and deletes. If you try to enforce that deleting a parent node in a tree deletes it's child nodes, you cannot, the compiler complains that a recursive relationship is not allowed, even though the only case that would actually produce the infinite recursion is self-referencing. This is a *new* feature, they cannot claim legacy support on this one. They are deliberately sacrificing power in the name of protecting the stupid developer from himself, and I for one am tired of it.

> >> Can you give a specific case where allowing relation-valued
> attributes would result in a wrong answer? Are you suggesting that
> allowing list, tuple, and relation-valued attributes somehow makes the
> language inconsistent (inconsistent in the formal sense meaning it
> would be possible to derive contradictory theorems)? <<
>
> The classic example for relation-valued columns is to put the table
> inside itself. Lazurus Long is his own great grandfather, if you are
> a Heinlein fan, and you fall into infinite recursion. A parts
> explosion suddenly has more assemblies than there are atoms in the
> Universe. I nest a table using the Ackermann function as my model
> (non-primitive recursion), Etc.

I can do this without relation-valued attributes using a simple self-referencing foreign key. This does not show that including relation-valued attributes makes the language inconsistent.

> The list stuff also has its problems -- look up Post Production
> strings. This was designed by the logician Emily Post to demonstrate
> unprovablity of what look like simple theorems. You are given a set
> of prodution rules and string; the rules involve cutting letters from
> the head and adding letters to the tail until the string either
> repeats a prior configuration (loopin) or comes to a halt state.
> Unfortunately, there is no way to know what the situation is in
> general.; It's basically the Turing Machine Halting problem in new
> clothes.
>
> In fact, any data structure more complex than a scalar can run into
> Mr. Godel and his friends. I am not bothered by having just simple
> scalar columns and unimaginative tables -- Number theory gets along
> fine with nothing but integers.

In fact, *any* formal system at least as powerful as typographical number theory (which a relational language certainly is, even without relation-valued attributes) is subject to the Godelian attack, it says *nothing whatsoever* about whether or not the system is useful. If we were limited to systems that were not subject to Mr. Godel and his friends, we wouldn't even be able to add. I remain unconvinced that introducing relation-valued attributes causes any problems that are not already present in a relational language.

Regards,
Bryn Received on Mon Jul 19 2004 - 20:13:53 CEST

Original text of this message