sql:1999, formerly known as sql3 - university of … · sql:1999, formerly known as sql3 andrew...
TRANSCRIPT
SQL:1999, formerly known as SQL3
Andrew EisenbergSybase, Concord, MA 01742
Jim MeltonSandy, UT 84093
BackgroundFor several years now, you’ve been hearing andreading about an emerging standard that everybodyhas been calling SQL3. Intended as a majorenhancement of the current second generation SQLstandard, commonly called SQL-92 because of theyear it was published, SQL3 was originally plannedto be issued in about 1996…but things didn’t go asplanned.
As you may be aware, SQL3 has beencharacterized as “object-oriented SQL” and is thefoundation for several object-relational databasemanagement systems (including Oracle’s ORACLE8,Informix’ Universal Server, IBM’s DB2 UniversalDatabase, and Cloudscape’s Cloudscape, amongothers). This is widely viewed as a “good thing”, butit has had a downside, too: it took nearly 7 years todevelop, instead of the planned 3 or 4.
As we shall show, SQL:1999 is much morethan merely SQL-92 plus object technology. Itinvolves additional features that we consider to fallinto SQL’s relational heritage, as well as a totalrestructuring of the standards documents themselveswith an eye towards more effective standardsprogression in the future.
Standards DevelopmentProcessThe two de jure organizations actively involved inSQL standardization, and therefore in thedevelopment of SQL:1999, are ANSI and ISO.
More specifically, the internationalcommunity works through ISO/IEC JTC1 (JointTechnical Committee 1), a committee formed by theInternational Organization for Standardization inconjunction with the International ElectrotechnicalCommission. JTC1’s responsibility is to develop andmaintain standards related to InformationTechnology. Within JTC1, Subcommittee SC32,titled Data Management and Interchange, wasrecently formed to take over standardization ofseveral standards related to database and metadatathat had been developed by other organizations (suchas the now-disbanded SC21). SC32, in turn, formed a
number of Working Groups to actually do thetechnical work—WG3 (Database Languages) isresponsible for the SQL standard, while WG4 isprogressing the SQL/MM (SQL MultiMedia, a suiteof standards that specify type libraries using SQL’sobject-oriented facilities).
In the United States, IT standards arehandled by the American National StandardsInstitute’s Accredited Standards DevelopmentCommittee NCITS (National Committee forInformation Technology Standardization, formerlyknown more simply as “X3”). NCITS TechnicalCommittee H2 (formerly “X3H2”) is responsible forseveral data management-related standards, includingSQL and SQL/MM.
When the first generation of SQL wasdeveloped (SQL-86 and its minor enhancement SQL-89), much—perhaps most—of the development workwas done in the USA by X3H2 and other nationsparticipated largely in the mode of reviewing andcritiquing the work ANSI proposed. By the timeSQL-89 was published, the international communitywas becoming very active in writing proposals for thespecification that became SQL-92; that has notchanged while SQL:1999 was being developed, nordo we believe it’s likely to change in the future—SQL is truly an international collaborative effort.
A work of explanation is in order about theinformal names we’re using for various editions ofthe SQL standard. The first versions of the standardare widely known as SQL-86 (or SQL-87, since theISO version wasn’t published until early 1987), SQL-89, and SQL-92, while the version just now beingfinalized should become known as SQL:1999. Whythe difference…why not “SQL-99”? Well, simplybecause we have to start thinking about what the nextgeneration will be called, and “SQL-02” seemedmore likely to be confused with “SQL2” (which wasthe project name under which SQL-92 wasdeveloped)…not to mention the fact that “02” isn’treally greater than “99”. In other words, we don’twant even the name of the SQL standard to sufferfrom the year 2000 problem!
Contents of SQL:1999With that background under our belts, it’s time totake a survey of the actual contents of SQL:1999.
While we recognize that most readers of this columnwill not know the precise contents of even SQL-92,space limitations prohibit our presenting the completefeature set of SQL:1999. Consequently, we’re goingto restrict our overview to just those features that arenew to this most recent generation of the SQLstandard.
The features of SQL:1999 can be crudelypartitioned into its “relational features” and its“object-oriented features”. We’ll cover them in thatsequence for convenience.
Relational FeaturesAlthough we call this category of features“relational”, you’ll quickly recognize that it’s moreappropriately categorized as “features that relate toSQL’s traditional role and data model”…a somewhatless pithy phrase. The features here are not strictlylimited to the relational model, but are also unrelatedto object orientation.
These features are often divided into aboutfive groups: new data types, new predicates,enhanced semantics, additional security, and activedatabase. We’ll look at each in turn.
New Data TypesSQL:1999 has four new data types (although
one of them has some identifiable variants). The firstof these types is the LARGE OBJECT, or LOB, type.This is the type with variants: CHARACTERLARGE OBJECT (CLOB) and BINARY LARGEOBJECT (BLOB). CLOBs behave a lot like characterstrings, but have restrictions that disallow their use inPRIMARY KEYs or UNIQUE predicates, inFOREIGN KEYs, and in comparisons other thanpurely equality or inequality tests. BLOBs havesimilar restrictions. (By implication, LOBs cannot beused in GROUP BY or ORDER BY clauses, either.)Applications would typically not transfer entire LOBvalues to and from the database (after initial storage,that is), but would manipulate LOB values through aspecial client-side type called a LOB locator. InSQL:1999, a locator is a unique binary value that actsas a sort of surrogate for a value held within thedatabase; locators can be used in operations (such asSUBSTRING) without the overhead of transferringan entire LOB value across the client-serverinterface.
Another new data type is the BOOLEANtype, which allows SQL to directly record truthvalues true, false, and unknown. Complexcombinations of predicates can also be expressed inways that are somewhat more user-friendly than theusual sort of restructuring might make them:
WHERE COL1 > COL2 AND COL3 = COL4 OR UNIQUE(COL6) IS NOT FALSE
SQL:1999 also has two new compositetypes: ARRAY and ROW. The ARRAY type allowsone to store collections of values directly in a columnof a database table. For example:
WEEKDAYS VARCHAR(10) ARRAY[7]
would allow one to store the names of all sevenweekdays directly in a single row in the database.Does this mean that SQL:1999 allows databases thatdo not satisfy first normal form? Indeed, it does, inthe sense that it allows “repeating groups”, whichfirst normal form prohibits. (However, some haveargued that SQL:1999’s ARRAY type merely allowsstorage of information that can be decomposed, muchas the SUBSTRING function can decomposecharacter strings—and therefore doesn’t truly violatethe spirit of first normal form.)
The ROW type in SQL:1999 is an extensionof the (anonymous) row type that SQL has alwayshad and depended on having. It gives databasedesigners the additional power of storing structuredvalues in single columns of the database:
CREATE TABLE employee ( EMP_ID INTEGER, NAME ROW ( GIVEN VARCHAR(30), FAMILY VARCHAR(30) ), ADDRESS ROW ( STREET VARCHAR(50), CITY VARCHAR(30), STATE CHAR(2) ) SALARY REAL )
SELECT E.NAME.FAMILYFROM employee E
While you might argue that this also violates firstnormal form, most observers recognize it as justanother “decomposable” data type.
SQL:1999 adds yet another data type-relatedfacility, called “distinct types”. Recognizing that it’sgenerally unlikely that an application would want,say to directly compare an employee’s shoe size withhis or her IQ, the language allows programmers todeclare SHOE_SIZE and IQ to each be “based on”INTEGER, but prohibit direct mixing of those twotypes in expressions. Thus, an expression like:
WHERE MY_SHOE_SIZE > MY_IQ
(where the variable name implies its data type) wouldbe recognized as a syntax error. Each of those twotypes may be “represented” as an INTEGER, but theSQL system doesn’t allow them to be mixed inexpressions—nor for either to be, say, multiplied byan INTEGER:
SET MY_IQ = MY_IQ * 2
Instead, programs have to explicitly express theirdeliberate intent when doing such mixing:
WHERE MY_SHOE_SIZE > CAST (MY_IQ AS SHOE_SIZE)
SET MY_IQ = MY_IQ * CAST(2 AS IQ)
In addition to these types, SQL:1999 hasalso introduced user-defined types, but they fall intothe object-oriented feature list.
New PredicatesSQL:1999 has three new predicates, one of whichwe’ll consider along with the object-orientedfeatures. The other two are the SIMILAR predicateand the DISTINCT predicate.
Since the first version of the SQL standard,character string searching has been limited to verysimple comparisons (like =, >, or <>) and the ratherrudimentary pattern matching capabilities of theLIKE predicate:
WHERE NAME LIKE '%SMIT_'
which matches NAME values that have zero or morecharacters preceding the four characters ‘SMIT’ andexactly one character after them (such as SMITH orHAMMERSMITS).
Recognizing that applications often requiremore sophisticated capabilities that are still short offull text operations, SQL:1999 has introduced theSIMILAR predicate that gives programs UNIX-likeregular expressions for use in pattern matching. Forexample:
WHERE NAME SIMILAR TO'(SQL-(86|89|92|99))|(SQL(1|2|3))'
(which would match the various names given to theSQL standard over the years). It’s slightlyunfortunate that the syntax of the regular expressionsused in the SIMILAR predicate doesn’t quite matchthe syntax of UNIX’s regular expressions, but some
of UNIX’s characters were already in use for otherpurposes in SQL.
The other new predicate, DISTINCT, is verysimilar in operation to SQL’s ordinary UNIQUEpredicate; the important difference is that two nullvalues are considered not equal to one another andwould thus satisfy the UNIQUE predicate, but not allapplications want that to be the case. The DISTINCTpredicate considers two null values to be not distinctfrom one another (even though they are neither equalto nor not equal to one another) and thus those twonull values would cause a DISTINCT predicate not tobe satisfied.
SQL:1999’s New SemanticsIt’s difficult to know exactly where to draw the linewhen talking about new semantics in SQL:1999, butwe’ll give a short list of what we believe to be themost important new behavioral aspects of thelanguage.
A long-standing demand of applicationwriters is the ability to update broader classes ofviews. Many environments use views heavily as asecurity mechanism and/or as a simplifier of anapplications view of the database. However, if mostviews are not updatable, then those applications oftenhave to “escape” from the view mechanism and relyon directly updating the underlying base tables; thisis a most unsatisfactory situation.
SQL:1999 has significantly increased therange of views that can be updated directly, usingonly the facilities provided in the standard. It dependsheavily on functional dependencies for determiningwhat additional views can be updated, and how tomake changes to the underlying base table data toeffect those updates.
Another widely-decried shortcoming of SQLhas been its inability to perform recursion forapplications such as bill-of-material processing. Well,SQL:1999 has provided a facility called recursivequery to satisfy just this sort of requirement. Writinga recursive query involves writing the queryexpression that you want to recurse and giving it aname, then using that name in an associated queryexpression:
WITH RECURSIVE Q1 AS SELECT...FROM...WHERE..., Q2 AS SELECT...FROM...WHERE...SELECT...FROM Q1, Q2 WHERE...
We’ve already mentioned locators as aclient-side value that can represent a LOB valuestored on the server side. Locators can be used in thesame way to represent ARRAY values, accepting the
fact that (like LOBs) ARRAYs can often be too largeto conveniently pass between an application and thedatabase. Locators can also be used to represent user-defined type values—discussed later in thiscolumn—which also have the potential to be largeand unwieldy.
Finally, SQL:1999 has added the notion ofsavepoints, widely implemented in products. Asavepoint is a bit like a subtransaction in that anapplication can undo the actions performed after thebeginning of a savepoint without undoing all of theactions of an entire transaction. SQL:1999 allowsROLLBACK TO SAVEPOINT and RELEASESAVEPOINT, which acts a lot like committing thesubtransaction.
Enhanced SecuritySQL:1999’s new security facility is found in its rolecapability. Privileges can be granted to roles just asthey can be to individual authorization identifiers,and roles can be granted to authorization identifiersand to other roles. This nested structure canenormously simplify the often difficult job ofmanaging security in a database environment.
Roles have been widely implemented bySQL products for several years (though occasionallyunder different names); the standard has finallycaught up.
Active DatabaseSQL:1999 recognizes the notion of active database,albeit some years after implementations did. Thisfacility is provided through a feature known astriggers. A trigger, as many readers know, is afacility that allows database designers to instruct thedatabase system to perform certain operations eachand every time an application performs specifiedoperations on particular tables.
For example, triggers could be used to logall operations that change salaries in an employeetable:
CREATE TRIGGER log_salupdate BEFORE UPDATE OF salary ON employees REFERENCING OLD ROW as oldrow NEW ROW as newrow FOR EACH ROW INSERT INTO log_table VALUES (CURRENT_USER, oldrow.salary, newrow.salary)
Triggers can be used for many purposes, not justlogging. For example, you can write triggers that
keep a budget balanced by reducing monies set asidefor capital purchases whenever new employees arehired…and raising an exception if insufficient moneyis available to do so.
Object OrientationIn addition to the more traditional SQL featuresdiscussed so far, SQL:1999’s development wasfocussed largely—some observers would say toomuch—on adding support for object-orientedconcepts to the language.
Some of the features that fall into thiscategory were first defined in the SQL/PSM standardpublished in late 1996—specifically, support forfunctions and procedures invocable from SQLstatements. SQL:1999 enhances that capability,called SQL-invoked routines, by adding a third classof routine known as methods, which we’ll get toshortly. We won’t delve into SQL-invoked functionsand procedures in this column, but refer you to anearlier issue of the SIGMOD Record [6].
Structured User-Defined TypesThe most fundamental facility in SQL:1999 thatsupports object orientation is the structured user-defined type; the word “structured” distinguishes thisfeature from distinct types (which are also “user-defined” types, but are limited in SQL:1999 to beingbased on SQL’s built-in types and thus don’t havestructure associated with them).
Structured types have a number ofcharacteristics, the most important of which are:– They may be defined to have one or more
attributes, each of which can be any SQL type,including built-in types like INTEGER,collection types like ARRAY, or other structuredtypes (nested as deeply as desired).
– All aspects of their behaviors are providedthrough methods, functions, and procedures.
– Their attributes are encapsulated through the useof system-generated observer and mutatorfunctions (“get” and “set” functions) that providethe only access to their values. However, thesesystem-generated functions cannot beoverloaded; all other functions and methods canbe overloaded.
– Comparisons of their values are done onlythrough user-defined functions.
– They may participate in type hierarchies, inwhich more specialized types (subtypes) have allattributes of and use all routines associate withthe more generalized types (supertypes), but mayadd new attributes and routines.
Let’s look at an example of a structured typedefinition:
CREATE TYPE emp_type UNDER person_typeAS ( EMP_ID INTEGER, SALARY REAL )INSTANTIABLENOT FINALREF ( EMP_ID )INSTANCE METHOD GIVE_RAISE ( ABS_OR_PCT BOOLEAN, AMOUNT REAL ) RETURNS REAL
This new type is a subtype of anotherstructured type that might be used to describe personsin general, including such common attributes as nameand address; the new emp_type attributes includethings that “plain old persons” don’t have, like anemployee ID and a salary. We’ve declared this typeto be instantiable and permitted it to have subtypesdefined (NOT FINAL). In addition, we’ve said thatany references to this type (see the discussion on REFtypes below) are derived from the employee IDvalue. Finally, we’ve defined a method (more on thislater) that can be applied to instances of this type.
SQL:1999, after an extensive flirtation withmultiple inheritance (in which subtypes were allowedto have more than one immediate supertype), nowprovides a type model closely aligned with Java’s—single inheritance. Type definers are allowed tospecify that a given type is either instantiable (inother words, values of that specific type can becreated) or not instantiable (analogous to abstracttypes on other programming languages). And,naturally, any place—such as a column—where avalue of some structured type is permitted, a value ofany of its subtypes can appear; this provides exactlythe sort of substitutability that object-orientedprograms depend on.
By the way, some object-orientedprogramming languages, such as C++, allow typedefiners to specify the degree to which types areencapsulated: an encapsulation level of PUBLICapplied to an attribute means that any user of the typecan access the attribute, PRIVATE means that nocode other than that used to implement the type’smethods can access the attribute, and PROTECTEDmeans that only the type’s methods and methods ofany subtypes of the type can access the attribute.SQL:1999 does not have this mechanism, althoughattempts were made to define it; we anticipate it to beproposed for a future revision of the standard.
Functions vs MethodsSQL:1999 makes an important distinction between“ordinary” SQL-invoked functions and SQL-invokedmethods. In brief, a method is a function with severalrestrictions and enhancements. Let’s summarize thedifferences between the two types of routine:– Methods are tightly bound to a single user-
defined type; functions are not.– The user-defined type to which a method is
bound is the data type of a distinguishedargument to the method (the first, undeclaredargument); no argument of a function isdistinguished in this sense.
– Functions may be polymorphic (overloaded), buta specific function is chosen at compile time byexamining the declared types of each argumentof a function invocation and choosing the “bestmatch” among candidate functions (having thesame name and number of parameters); methodsmay also be polymorphic, but the most specifictype of their distinguished argument, determinedat runtime, allows selection of the exact methodto be invoked to be deferred until execution; allother arguments are resolved at compile timebased on the arguments’ declared types.
– Methods must be stored in the same schema inwhich the definition of their tightly-boundstructured type is stored; functions are notlimited to a specific schema.
Both functions and methods can be writtenin SQL (using SQL/PSM’s computationally-completestatements) or in any of several more traditionalprogramming languages, including Java.
Functional and Dot NotationsAccess to the attributes of user-defined types can bedone using either of two notations. In manysituations, applications may seem more natural whenthey use “dot notation”:
WHERE emp.salary > 10000
while in other situations, a functional notation may bemore natural:
WHERE salary(emp) > 10000
SQL:1999 supports both notations; in fact,they are defined to be syntactic variations of the samething—as long as “emp” is a storage entity (like acolumn or variable) whose declared type is somestructured type with an attribute named“salary”…or there exists a function named
“salary” with a single argument whose data type isthe (appropriate) structured type of emp.
Methods are slightly less flexible thanfunctions in this case: Only dot notation can be usedfor method invocations—at least for the purposes ofspecifying the distinguished argument. If salarywere a method whose closely bound type were, say,employee, which was in turn the declared type of acolumn named emp, then that method could beinvoked only using:
emp.salary
A different method, say give_raise, cancombine dot notation and functional notation:
emp.give_raise(amount)
Objects…FinallyCareful readers will have observed that we haveavoided the use of the word “object” so far in ourdescription of structured types. That’s because, inspite of certain characteristics like type hierarchies,encapsulation, and so forth, instances of SQL:1999’sstructured types are simply values, just like instancesof the language’s build-in types. Sure, an employeevalue is rather more complex (in appearance, as wellas in behavior) than an instance of INTEGER, but it’sstill a value without any identity other than thatprovided by its value.
In order to gain the last little bit ofcharacteristic that allows SQL to provide objects,there has to be some sense of identity that can bereferenced in a variety of situations. In SQL:1999,that capability is supplied by allowing databasedesigners to specify that certain tables are defined tobe “typed tables”…that is, their column definitionsare derived from the attributes of a structured type:
CREATE TABLE empls OF employee
Such tables have one column for eachattribute of the underlying structured type. Thefunctions, methods, and procedures defined tooperate on instances of the type now operate on rowsof the table! The rows of the table, then, are valuesof—or instances of—the type. Each row is given aunique identity that behaves just like a OID (objectidentifier) behaves…it is unique in space (that is,within the database) and time (the life of thedatabase).
SQL:1999 provides a special type, called aREF type, whose values are those unique identifiers.A given REF type is always associated with aspecified structured type. For example, if we were to
define a table containing a column named “manager”whose values were references to rows in a typed tableof employees, it would look something like this:
manager REF(emp_type)
A value of a REF type either identifies a rowin a typed table (of the specified structured type, ofcourse) or it doesn’t identify anything at all—whichcould mean that it’s a “dangling reference” left overafter the row that it once identified was deleted.
All REF types are “scoped” so that the tablethat they reference is known at compilation time.During the development of SQL:1999, there wereefforts made to allow REF types to be more generalthan that (for example, any of several tables could bein the scope, or any table at all of the appropriatestructured type would be in the scope even if thetable were created after the REF type was created);however, several problems were encountered thatcould not be resolved without further delayingpublication of the standard, so this restriction wasadopted. One side effect of the restriction, possibly abeneficial effect, is that REF types now behave verymuch like referential integrity, possibly easing thetask of implementing this facility in some products!
Using REF TypesYou shouldn’t be surprised to learn that REF typescan be used in ways a little more sophisticated thanmerely storing and retrieving them.
SQL:1999 provides syntax for “following areference” to access attributes of a structured typevalue:
SELECT emps.manager->last_name
The “pointer” notation (->) is applied to avalue of some REF type and is then “followed” intothe identified value of the associated structuredtype—which, of course, is really a row of the typedtable that is the scope of the REF type. Thatstructured type is both the type associated with theREF type of the manager column in the emps tableand the type of that other table (whose name isneither required nor apparent in this expression).However, that structured type must have an attributenamed last_name, and the typed table thus has acolumn of that name.
Schedules and FuturesSQL:1999 is not yet a standard, although it’s well onits way to becoming one. Last year, what is called theFinal Committee Draft (FCD) ballot was held for
four parts of the SQL specifications (see references[1], [2], [4], and [5]). In November, 1998, the finalround of the Editing Meeting was held for thoseparts. The changes to the specifications have beenapplied by the Editor (Jim Melton) and are now beingreviewed by Editing Meeting participants. Whenthose reviews are completed, those fourspecifications will be submitted for one last ballot(called a Final Draft International Standard, or FDIS,ballot), the result of which is either “approve andpublish without change” or “disapprove and go backto FCD status”. All participants currently anticipatethat the result will be to approve and publish,resulting in a revised standard sometime in mid-1999.
Another part of SQL, SQL/CLI (seereference [3]), is also being revised and has justundergone an FCD ballot. It is expected that it will bepublished later in 1999 as a revision of the CLI-95standard.
It’s hard to know what the future will bring,but both the ANSI and ISO groups are committed toavoiding the lengthy process that resulted inSQL:1999. We all believe that 6 years is simply toolong, especially with the world working in “webtime” more and more. Instead, plans are beingdeveloped that will result in revisions being issuedroughly every three years, even if the technicalenhancements are somewhat more modest than thosein SQL:1999.
In addition to evolving the principle parts ofthe SQL:1999 standard, additional parts of SQL arebeing developed to address such issues as temporaldata, the relationship with Java (explored in theprevious issue of the SIGMOD Record), andmanagement of external data along with SQL data.
Recognition of IndividualContributorsThere have been many, many people involved in thedevelopment of SQL:1999 over the years itsdevelopment occupied. While we don’t have thespace to mention everybody who participated in thecommittees during its development, we do think itappropriate to mention at least the names of peoplewho wrote significant numbers of change proposalsor simply wrote significant proposals.– Mihnea Andrei (France; Sybase)– Jon Bauer (USA; Digital and Oracle)– David Beech (USA; Oracle)– Ames Carlson (USA; HP and Sybase)– Stephen Cannan (Netherlands; DCE Nederland
and James Martin Consulting)– Paul Cotton (Canada; IBM)– Hugh Darwen (UK; IBM)– Linda deMichael (USA; IBM)
– Judy Dillman (USA; CA)– R diger Eisele (Germany; Digital and
independent consultant)– Andrew Eisenberg (USA; Digital, Oracle, and
Sybase)– Chris Farrar (USA; Teradata and Compaq)– Len Gallagher (USA; NIST)– Luigi Giuri (Italy; Fondazione ugo Bordoni)– Keith Hare (USA; JCC)– Bruce Horowitz (USA; Bellcore)– Bill Kelly (USA; UniSQL)– Bill Kent (USA; HP)– Krishna Kulkarni (USA; Tandem, Informix, and
IBM)– Nelson Mattos (USA; IBM)– Jim Melton (USA; Digital and Sybase)– Frank Pellow (Canada; IBM and USA;
Microsoft)– Baba Piprani (Canada; independent consultant)– Peter Pistor (Germany; IBM)– Mike Pizzo (USA; Microsoft)– Jeff Richie (USA; Sybase and IBM)– Phil Shaw (USA; IBM, Oracle, and Sybase)– Kohji Shibano (Japan; Tokyo International
University and Tokyo University of ForeignStudies)
– Masashi Tsuchida (Japan; Hitachi)– Mike Ubell (USA; Digital, Illustra, and
Informix)– Murali Venkatrao (USA; Microsoft)– Fred Zemke (USA; Oracle)
Each of these people contributed in somesignificant way. Some of them designed majoraspects of the architecture of SQL:1999, othersfocussed on specific technologies like the call-levelinterface (SQL/CLI), while others worked on veryfocussed issues, such as security. They are all—as areother contributors not mentioned here—to becongratulated on a large job well done.
References[1] ISO/IEC 9075:1999,Information technology—
Database languages—SQL—Part 1: Framework(SQL/Framework), will be published in 1999.
[2] ISO/IEC 9075:1999,Information technology—Database languages—SQL—Part 2: Foundation(SQL/Foundation), will be published in 1999.
[3] ISO/IEC 9075:1999,Information technology—Database languages—SQL—Part 3: Call-LevelInterface (SQL/CLI), will be published in 1999.
[4] ISO/IEC 9075:1999,Information technology—Database languages—SQL—Part 4: PersistentStored Modules (SQL/PSM), will be published in1999.
[5] ISO/IEC 9075:1999,Information technology—Database languages—SQL—Part 5: HostLanguage Bindings (SQL/Bindings), will bepublished in 1999.
[6] New Standard for Stored Procedures in SQL,Andrew Eisenberg, SIGMOD Record, Dec.1996
The SQL specifications will be available in theUnited States from:
American National Standards InstituteAttn: Customer Service11 West 42nd StreetNew York, NY 10036USA
Phone: +1.212.642.4980
It will be available internationally from thedesignated National Body in each country or from:
International Organization for Standardization1, rue de Varemb
Case postale 56 CH-1211 Gen ve 20 Switzerland
Phone: +41.22.749.0111
Web ReferencesAmerican National Standards Institute (ANSI)
http://web.ansi.org
International Organization for Standardization (ISO)http://www.iso.ch
JTC1 SC32 – Data Management and Interchangehttp://bwonotes5.wdc.pnl.gov/SC32/JTC1SC32.nsf
National Committee for Information TechnologyStandards (NCITS)
http://www.ncits.org
NCITS H2 – Databasehttp://www.ncits.org/tc_home/h2.htm