Re: Correction

Dieter

> On Monday, 8 September 2014 16:19:15 UTC+10, Dieter Nöth  wrote:
>
> As I'm a Teradata guy I'd be interested in the "finite SQL" Teradata 
> implemented. Could you show some SQL for me?

Great.

The correction was due to the list of *commercial SQLs*, and Teradata is right up there.

I haven't used Teradata SQL in years, but I won't avoid the question. Beyond doubt, it limits the "Null Problem" issues as I have described above. The main issue that the non-commercial SQLs and Non-SQLs have is:

1 inconsistency in treatment of Nulls that may occur in the result set (relations, projections, as opposed to Nulls in physical rows, which are a separate issue)
-- which means aggregates may or may not include relations with NULL in the relevant column

2 the "finiteness" is absent:
-- NULL does not equal NULL

• any value (based on the domain of the column) sometimes equals NULL, other times not
• testing for NULL or the empty set is inconsistent

The commercial SQLs have cleaned that up, and supplied a predictable language, that does not require the programmer to sit and ponder The Null Problem, or 3VL, at every SELECT.
-- aggregates exclude relations with NULL in the relevant column

• NULL equals NULL
• any value (based on the domain of the column), other than NULL, does not equal NULL
• testing for NULL or the empty set is simple and consistent

3 Storing NULL in the data store (which is a stupid thing to do), is a different problem. I did not intend it to be part of the problem I was attacking in this thread, but I will if I have to. Storing NULLS is in fact *implementing* the Null Problem, where there was not a problem. Point being, there is no value is proving that stored NULLs have the cancer that was injected into the patient, who did not have the cancer before the injection of stored NULLs.

No Commercial SQL, or Act of God, can help you if you inject cancer into patients who do not have it. It is beyond the scope of a platform.

--

Let us avoid, if we can, navigating through the morass of "The Null Problem", and "3VL".  If we can, otherwise let us embark on that labour.

I am saying it is finite.  Short of writing a book, it is not reasonable to prove that.  I am saying Date, Darwen, Fagin, and the rest of the cursed ones who write books, and the university lecturers who follow them like lemmings, have all used Straw Man or otherwise invalid examples, and their proposals which are based on such invalid examples, are false.

I don't have any non-finite Teradata code that I have changed to finite (I did that probably 30 or 40 times, years ago). With those qualifiers in mind, why don't we go the other way, it is easier than supplying the book, or dreaming up an example, which may fall short.   Give me some Teradata SQL that you propose is not finite, or that you have some problem (related to the Null Problem) with, that operates on some rows that comply with the RM, and I will reply with the finite, commercial version.  

That will also eliminate any confusion between you and me re what "finite" means.  Otherwise I have to give you a definition (at this stage it is a description, rather than a definition), and I decry private definitions.

Alternative.  Feel free to use one of the examples in any of the non-Codd books, I have corrected or fixed up every single one that has been put to me. Or burnt the Straw Man, and the author with it, in effigy.

Re [3].  Complete Normalisation eliminates Nulls in the data store.  if your non-finite issue is a result of incomplete or incorrect Normalisation, I am happy to supply the correction for that.

If you don't have any TeradataSQL non-finite problem, then my statement that it (both TeradataSQL and the greater scope of Commercial SQLs) is finite, stands.

Cheers
Derek