[net.database] ANSI SQL2 standard - users beware :-)

csr@druhi.UUCP (RoushCS) (10/29/86)

  After looking briefly at the proposed ANSI standard for SQL and
talking to one member of the committee, I am mystified!  The standard
does not include any definition of an interactive query language.
Gosh, I thought SQL started as a query language.
  This does not mean that vendors will throw away their query language
implementations, just that there is no standard for an interactive
version of the language.
  So what, you say? 
- "select * from employee" (where employee is a valid table) is NOT a 
  valid command.  Neither is "select empname from employee" (where empname
  is a valid column).  (They are valid as part of a 'cursor declaration',
  but not as stand-alone statements).
- There is no way to delete a table, you can delete all the rows (records),
  but not the table.
- The only place the "create table ..." expression is valid is as PART of
  a "create schema" statement.  This is the only statement in the 'data
  definition language'.  Yes, a different language (with only one
  statement type) is required when you create tables.

  What does this mean?  I think it means that there will be no guarantee
of portability for programs written in the interactive versions of SQL
that are out there.  But, take heart, they are standardizing the
interface to PL/1.  (OK, this is a cheap shot, they also are
standardizing the interfaces to C, fortran, pascal, ...).

  Am I just confused about all this?  Anybody care to comment?

p.s.
  Hey committee: is it intentional that there are no delimiters between
<schema elements> and no terminator for a <schema> statement?

steve roush
AT&T Information Systems
Denver, CO
303-538-4860
ihnp4!druhi!csr

jag@ptsfa.UUCP (Jim Goncher) (10/31/86)

Why bother is RIGHT !

In recent conversations with RDBMS vendors other than IBM, they state
that they will work toward a "standard" implementation of SQL - both
interactive and HLI(Host Language Interface). They also stated that
when there is a conflict between the ANSI standard and the IBM "standard",
they will adopt the IBM "standard". These vendors are some of the leading
independents. Therefore, I reluctantly believe that the ANSI problem is moot.
 
Furthermore, these same vendors all offer extensions to ANSI and IBM SQL
that are very attractive and useful. If their products are acquired because
of some conformance to any "standard" - ANSI or IBM, would you NOT use the
extensions ? If you do use them, the "standard" again becomes moot. 
 
I think reality is that vendors will try to implement some form of SQL,
claim that it is "compatible" with somebody's "standard",  and add their
extensions for competitive reasons. Expectations of full conformance to
anything are very naive.
 
Lastly, I don't think we should be all that concerned with an SQL standard
expecting that if implemented it would be something that we would use for
a very long time to come. I give SQL ten years at the most before it is
replaced by something much more powerful with the semantics that SQL lacks.
There are already products coming on the market with this capability.
Of course, I could be seriously wrong here. I work in an envirnonment that
includes IBM's IMS and DL/I. Many have predicted that relational systems
would be its death knoll in the not too distant future. This certainly
remains to be seen. Meanwhile, any closely "compatible" conformance to
a database language "standard" is more that we could have hoped for five
years ago.
-- 
Jim Goncher - Pacific Bell -   {ihnp4,dual,qantel,lll-crg}!ptsfa!jag