ISO/IEC 12227:1995

INTERNATIONAL
ISO/IEC
STANDARD
First edition
1995-02-15
Information technology - Programming
languages - SQL/Ada Module Description
Language (SAMeDL)
Technologies de I ’informa tion - Langages de programmation - Langage
de description de modules SQUAda (SAMeDL)
Reference number
ISO/1 EC 12227: 1995(E)
Page
1 Scope
2 Normative references
3 Notations and Structures
3.1 Syntax Notation
3.2 Semantic Notation
3.3 Structure
3.4 Examples, Notes and Index Entries
4 Design Goals and Language Summary
4.1 Design Goals
4.2 Language Summary
4.2.1 Overview
4.2.2 Compilation Units
4.2.3 Modules
4.2.4 Procedures and Cursors
4.25 Domain and Base Domain Declarations
4.2.6 Other Declarations
4.2.7 Value Expressions and Typing
4.2.8 Standard Post Processing
4.2.9 Extensions
4.2.10 Default Values in Grammar
4.3 Entry Level SQL
5 Lexical Elements
5.1 Character Set
5.2 Lexical Elements, Separators, and Delimiters
5.3 Identifiers
5.4 Literals and Data Classes
5.5 Comments
5.6 Reserved Words
0 ISO/IEC 1995
All rights reserved. Unless otherwrse specified, no part of this publication may be reproduced
or utilized in any form or by any means, electronie or mechanical, including photocopytng and
microfilm, without Permission in writing from the publisher.
I SO/I EC Copyright Office l Case Postale 56 l CH-l 211 Geneve 20 l Switzerland
Printed in Switzerland
ii
o lSO/IEC
ISO/IEC 12227: 1995(E)
6 Common Elements
6.1 Compilation Units
6.2 Context Clause
6.3 Table Names and the From Clause
6.4 References
6.5 Assignment Contexts and Conformance of an Expression to a Domain
6.6 Standard Post Processing
6.7 Extensions
7 Data Description Language and Data Semantics
7.1 Definitional Modules
7.1.1 Base Domain Declarations
7.1 .l .l Base Domain Parameters
7.1 .1.2 Base Domain Patterns
7.1 J.3 Base Domain Options
7.1.2 The SAME Standard Base Domains
7.1.3 Domain and Subdomain Declarations
7.1.4 Constant Declarations
7.1.5 Record Declarations
7.1.6 Enumeration Declarations
7.1.7 Exception Declarations
7.1.8 Status Map Declarations
7.2 Schema Modules
7.2.1 Table Definitions
7.2.2 View Definitions
7.3 Data Conversions
8 Abstract Module Description Language
8.1 Abstract Modules
8.2 Procedures
8.3 Statements
8.4 Cursor Declarations
8.5 Cursor Procedures
8.6 Input Parameter Lists
8.7 Select Parameter Lists
8.8 Value Lists and Column Lists
- -
8.9 Into - Clause and Insert From Clause
8.10 Value Expressions
8.11 Search Conditions
8.12 Subqueries
8.13 Status Clauses
9 Conformance
9.1 Introduction
9.2 Claims of Conformance
9.2.1 Introduction
9.2.2 Conformance via mapping.
9.2.2.1 Conformance via SQL module.
9.2.2.2 Conformance via embedded SQL Syntax.
. . .
Ill
o lSO/IEC
lSO/IEC 12227:1995(E)
9.2.3 Conformance via effects.
9.2.4 Multiple Claims of conformance.
9.3 Extensions
Annex A. SAMeDL Standard
-
Annex B. SAMeDL System
-
Annex C. Standard Support Operations and Specifications
C.l Standard Base Domain Operations
C.l .l All Domains
Cl .2 Numeric Domains
C.1.3 Int and Smallint Domains
C. 1.4 Character Domains
C.1.5 Enumeration Domains
C.1.6 Boolean Functions
C.1.7 Operations Available to the Application
C.2 Standard Support Package Specifications
C.2.1 SQL Standard
C.2.2 SQLIBoolean-Pkg
C.2.3 SQL-lnt-Pkg
C.2.4 SQL-Smallint-Pkg
C.2.5 SQL-Real-Pkg
C.2.6 SQL-Double-Precision-Pkg
C.2.7 SQL-Char-Pkg
C.2.8 SQL-Enumeration-Pkg
Annex D. Transform Chart
Annex E. Glossary
Annex F. References
Index
o lSO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized System for
worldwide standardization. National bodies that are members of ISO or
IEC participate in the development of International Standards through
technical committees established by the respective organization to deal
with particular fields of technical activity. ISO and IEC technical com-
mittees collaborate in fields of mutual interest. Other international organ-
izations, governmental and non-governmental, in liaison with ISO and IEC,
also take part in the work.
In the field of information technology, ISO and IEC have established a joint
technical committee, lSO/IEC JTC 1. Draft International Standards adopted
by the joint technical committee are circulated to national bodies for vot-
ing. Publication as an International Standard requires approval by at least
75 % of the national bodies casting a vote.
International Standard lSO/lEC 12227 was prepared by Joint Technical
Committee lSO/IEC JTC 1, Information technology, Subcommittee SC 22,
Programming languages, their environments and System Software inter-
faces.
Annexes A to C form an integral part of this International Standard. An-
nexes D to F are for information only.
V
This page intentionally left blank

INTERNATIONAL STANDARD o ISO/IEC
Information technology - Programming languages - SQUAda
Module Description Language (SAMeDL)
1 Scope
This International Standard specifies the Syntax and semantics of a database programming language, the SQL
Ada Module Description Language, SAMeDL. Texts written in the SAMeDL describe database interactions which
are to be performed by database management Systems (DBMS) implementing Database Language SQL. The
interactions so described and so implemented are to be petformed on behalf of application programs written in
Programming Language Ada.
The SAMeDL is not a Programming Language; it may be used solely to specify application program database
interactions and solely when those interactions are to occur between an Ada application program and an SQL
DBMS.
The SAMeDL is defined with respect to Entry Level SQL. Therefore, all inclusions by reference of text from
ISO/IEC 90751992 include all applicable Leveling Rules for Entry Level SQL.
This International Standard does not define the Programming Language Ada nor the Database Language SQL.
Therefore, ISO 8652:1987 takes precedence in all matters dealing with the Syntax and semantics of any Ada
construct contained, referred or described within this International Standard; similarly, ISO/1 EC 9075: 1992 takes
precedence in all matters dealing with the Syntax and semantics of any SQL construct contained, referred or
described within this International Standard.
Note: The SAMeDL is an example of an Abstract Modular Interface. A reference model for programming lan-
guage intetfaces to database management Systems, which includes a description of Abstract Modular interfaces,
tan be found in reference [2].
2 Normative references
The following International Standards contain provisions which, through reference in this text, constitute provi-
sions of this International Standard. At the time of publication, the editions indicated were valid. All International
Standards are subject to revision, and Parties to agreements based on this International Standard are en-
couraged to investigate the possibility of applying the most recent editions of the International Standards in-
dicated below. Members of IEC and ISO maintain registers of currently valid International Standards.
ISO/1 EC 9075: 1992, Information technology -- Database languages -- SQL.
ISO/IEC 8652: 1995, Information technology -- Programming languages -- Ada.
Scope 1
ISO/IEC 12227: 1995(E)
o lSO, ‘IEC
3 Notations and Structures
3.1 Syntax Notation
The tontext-free Syntax of the language is described using a simple variant of the variant of BNF used in the
description of Ada, (1.5 in ISO 8652:1987). The Variation is:
-- Underscores are preserved when using the name of a syntactic category outside of a Syntax rule (1.5(6) of
ISO 8652:1987).
-- The italicized prefixes Ada and SQL, when appearing in the names of syntactic categories, indicate that an
Ada or SQL syntactic category has been incorporated into this document. For example, the category
Ada identifier is identical to the category identifier as described in 2.3 of ISO 8652:1987; whereas the
category SQL identifier is identical to the category identifier as described in 5.4 of ISO/lEC 9075:1992.
-
-- Numerital suffixe s attac hed to the names of syntactic categories are used to distinguish appearances of the
category within a rule or set of rules. An exa mple of this usage is given below.
3.2 Semantic Notation
The meaning of a SAMeDL compilation unit (except where specified as implementation-defined) is given by:
-- An Ada compilation unit, conforming to ISO 8652:1987.
-- A module conforming to clause 12 of ISO/IEC 9075:1992.
-- Interface rules, concerning the relationship between the SQL and Ada texts.
The semantics of SAMeDL constructs are given in part by collections of string transformers that produce Ada
and SQL texts from SAMeDL input.
Note: A quick reference to these transformers appears in Annex D.
The effects of these transformers are described through the use of Sample input strings. Those strings are
written in a variant of the Syntax notation. For example, the Syntax of an input-Parameter (see 8.6) is given by:
identifier- 1 [namedshrase] : domain-reference [notnull]
A representative input Parameter declaration is given by
Id 1 [named Id 21 : Id 3 [not null]
- - -
lt is then possible to discuss the four variants of input Parameters (the variants described by the presence or
Single piece of text.
absence of optional phrases) in a
2 Database Programming Language - SAMeDL

o lSO/IEC
3.3 Structure
The remainder of this International Standard is structured in the following way. Clause 4 contains a descriptive
overview of the goals and concepts of the SAMeDL. Clause 5 defines the lexical structure of the SAMeDL
including the rules for identifier and Iiteral formation and the list of reserved words. Clauses 6, 7 and 8 define 2he
Syntax and semantics of the SAMeDL. Esch subclause of those clauses adheres to the following general format.
-- The purpose of the item being defined by the subclause is introduced.
-- The Syntax of the item being defined is given in the notation described earlier.
-- Abstract (non-context free) syntactical rules governing formation of instances of the item being defined are
given, if applicable.
-- The semantics of the item being defined are given. These semantics are given under the headings Ada
Semantics, SQL Semantics and Interface Semantics, as appropriate.
3.4 Examples, Notes and Index Entries
Many of the subclauses of this International Standard are illustrated with examples. These examples are intro-
duced by the words: “Note: Examples” on a line by themselves and are terminated by the words “End Ex-
amples,” likewise appearing on a line by themselves.
Note: Examples
This is an example of an example.
End Examples
Other notes also appear in this International Standard, introduced by the word Note. Both kinds of note are
informative only and do not form part of the definition of the SAMeDL.
Items in the grammar that contain underscores are represented in the Index by a corresponding entry without
underscores. For example, the “Ada identifier” entry in the index contains the page numbers of occurrences of
both “Ada identifier” and “Ada identifier ”.
-
4 Design Goals and Language Summary
4.1 Design Goals
The SQL Ada Module Description Language (SAMeDL) is a Database Programming Language designed to
automate the construction of Software conformant to the SQL Ada Module Extensions (SAME) application ar-
chitecture. This architecture is described in the document, Guidelines for the Use of the SAME [l].
The SAME is a modular architecture. lt uses the concept of a Module as defined in 4.16 and 12 of ISO/IEC
9075:1992. As a consequence, a SAME-conformant Ada application does not contain embedded SQL state-
ments and is not an embedded SQL Ada program as defined in 19.3 of ISO/IEC 90751992. Such a SAME-
conformant application treats SQL in the manner in which Ada treats all other languages: it imports complete
functional modules, not language fragments.
Notations and Structures 3
ISO/IEC
Modular architectures treat the interaction of the application program and the database as a design Object. This
results in a further isolation of the application program from details of the database design and implementation
and improves the potential for increased specialization of Software development staff.
Ada and SQL are vastly different languages: Ada is a Programming Language designed to express algorithms,
while SQL is a Database Language designed to describe desired results. Text containing both Ada and SQL is
therefore confusing and difficult to maintain. SAMeDL is a Database Programming Language designed to sup-
port the goals and exploit the capabilities of Ada with a language whose Syntax and semantics is based firmly in
SQL. Beyond modularity, the SAMeDL provides the application programmer the following Services:
-- An abstract treatment of null values. Using Ada typing facilities, a safe treatment of missing information
based on SQL is introduced into Ada database programming. The treatment is safe in that it prevents an
application from mistaking missing information (null values) for present information (non-null values).
-- Robust Status code processing. SAMeDL ’s Standard Post Processing provides a structured mechanism for
the processing of SQL Status Parameters.
-- Strong typing. SAMeDL ’s typing rules are based on the strong typing of Ada, not the permissive typing of
SQL.
-- Extensibility. The SAMeDL supports a class of user extensions. Further, it controls, but does not restritt,
implementation defined extensions.
4.2 Language Summary
4.2.1 Overview
The SAMeDL is designed to facilitate the construction of Ada database applications that conform to the SAME
architecture as described in [l]. The SAME method involves the use of an abstract interface, an abstract module,
a concrete interface, and a concrete module. The abstract interface is a set of Ada package specifications
containing the type and procedure declarations to be used by the Ada application program. The abstract module
is a set of bodies for the abstract interface. These bodies are responsible for invoking the routines of the
concrete interface, and converting between the Ada and the SQL data and error representations. The concrete
interface is a set of Ada specifications that define the SQL procedures needed by the abstract module. The
concrete module is a set of SQL procedures that implement the concrete interface.
Within this International Standard, the concrete module of [l] is called an SQL module and its contents are given
under the headings SQL Semantics within the clauses of this specification. The abstract modules of [l] are
given under the heading Ada Semantics within the clauses of this specification.
4.2.2 Compilation Units
A compilation unif consists of one or more modules. A module may be either a definitional module containing
shared definitions, a Schema module containing table, view, and privilege definitions, or an abstract module
containing local definitions and procedure and cursor declarations.
4 Database Programming Language - SAMeDL

o lSO/IEC ISO/IEC 12227:1995(E)
4.2.3 Modules
A definifional module contains the definitions of base domains, domains, constants, records, enumerations,
exceptions, and Status maps. Definitions in definitional modules may be seen by other modules.
A Schema module contains the definitions of tables, views, and Privileges.
An abstrac~ module defines (a portion of) an application ’s interface to the database: it defines SQL Services
needed by an Ada application program. An abstract module may contain procedure declarations, cursor
declarations, and definitions such as those that may appear in a definitional module. Definitions in an abstract
module, however, may not be seen by other modules.
4.2.4 Procedures and Cursors
A procedure declaration defines a basic database Operation. The declaration defines an Ada procedure decla-
ration and a corresponding SQL procedure. A SAMeDL procedure consists of a Single Statement along with an
optional input Parameter list and an optional Status clause. The input Parameter list provides the mechanism for
passing information to the database at runtime. A Statement in a SAMeDL procedure may be a commit state-
ment, rollback Statement, insert Statement query, insert Statement values, update Statement, select Statement or
an implementation-defined extended Statement. The semantics of a SAMeDL Statement directly parallel that of
its corresponding SQL Statement.
SAMeDL cu~sor declarations directly parallel SQL cursor declarations. In contrast to the language of ISO/IEC
90751992, the procedures that operate on cursors, procedures containing either an open, fetch, close, update
positioned or delete positioned Statement, are packaged with the declaration of the cursor upon which they
operate, thereby improving readability. Further, if no procedure containing an open, fetch or close Statement is
explicitly given in a cursor declaration, the language provides such procedures implicitly, thereby improving
writeability (ease of use).
4.2.5 Domain and Base Domain Declarations
Objects in the language have an associated domain, which characterizes the set of values and applicable
operations for that Object. In this sense, a domain is similar to an Ada type.
A base domain is a template for defining domains. A base domain declaration consists of a set of Parameters, a
set of Patterns and a set of Options. The Parameters are used to supply information needed to declare a domain
or subdomain derived from the base domain. Patterns contain templates for the generation of Ada code to
support the domain in Ada applications. This code generally contains type declarations and package instan-
tiations. Options contain information needed by the Compiler. Parameters may be used in the Patterns and
Options and their values may be referenced in other Statements.
Base domains are classified according to their associated data class. A data class is either integer, fixed, float,
enumeration, or Character. A numeric base domain has a data class of either integer, fixed, or float. An
enumeration base domain has a data class of enumeration, and defines both an ordered set of distinct enumera-
tion Iiterals and a bijection between the enumeration literals and their associated database values. A Character
base domain has a data class of Character.
Design Goals and Language Summary 5

ISO/IEC 12227: 1995(E) o lSO/IEC
4.2.6 Other Declarations
Certain SAMeDL declarations are provided as a convenience for the User. For example, constant declarations
name and associate a domain with a static expression. Record declarations allow distinct procedures to share
types. An exception declaration defines an Ada exception declaration with the same name.
4.2.7 Value Expressions and Typing
Value expressions are formed and evaluated according to the rules of SQL, with the exception that the strong
typing rules are based on those of Ada. In the typing rules of the SAMeDL, the domain acts as an Ada type in a
System without user defined operations. Strong typing necessitates the introduction of domain conversions.
These conversions are modeled after Ada type conversions; the operational semantics of the SAMeDL domain
conversion is the null Operation or identity mapping. The language rules specify that an informational message
be displayed under circumstances in which this departure from the Ada model has visible effect.
4.2.8 Standard Post Processing
Standardpostprocessing is performed after the execution of an SQL procedure but before control is returned to
the calling application procedure. The Status clause from a SAMeDL procedure declaration attaches a Status
mapping to the application procedure. That Status mapping is used to process SQL Status data in a uniform way
for all procedures and to present SQL Status Codes to the application in an application-defined manner, either as
a value of an enumerated type, or as a user defined exception. SQL Status Codes not specified by the Status
map result in a call to a Standard database error processing procedure and the raising of the predefined
SAMeDL exception, SQL Database Error. This prevents a database error from being ignored by the applica-
- -
tion.
4.2.9 Extensions
The data semantics of the SAMeDL may be extended without modification to the language by the addition of
user-defined base domains. For example, a user-defined base domain of DATE may be included without
modification to the SAMeDL.
DBMS specific (i.e., non-Standard) operations and features that require Compiler modification (e.g., dynamic
SQL) may also be included into the SAMeDL. Such additions to the SAMeDL are referred to as extensions.
Schema elements, table elements, Statements, query expressions, query specifications, and cursor Statements
may be extended. The modules, tables, views, cursors, and procedures that contain these extensions are
marked (with the keyword extended) to indicate that they go outside the Standard.
4.2.10 Default Values in Grammar
Obvious but overridable defaults are provided in the grammar. For example, open, close, and fetch Statements
are essential for a cursor, but their form may be deduced from the cursor declaration. The SAMeDL will therefore
supply the needed open, close, and fetch procedure declarations if they are not supplied by the User.
6 Database Programming Language - SAMeDL

o lSO/IEC ISO/IEC 12227: 1995(E)
4.3 Entry Level SQL
Within the text of this specification, the name SQL references the language known as Entry Level SQL in
ISO/IEC 9075:1992. Features and capabilities of ISO/IEC 9075:1992 that do not lie within Entry Level SQL may
be implemented via the extension facility defined in this International Standard. See 6.7 of this specification.
5 Lexical Elements
The text of a compilation is a sequence of lexical elements, each composed of characters from the basic charac-
ter set. The rules of composition are given in this chapter.
5.1 Character Set
The only characters allowed in the text of a compilation are the basic characters and the characters that make
up Character Iiterals (described in 5.4 of this specification). Esch Character in the basic Character set is
represented by a graphical Symbol.
basic Character ::=
ubper-case-letter 1 lower-case-letter 1 digit 1
special-Character 1 space-Character
The characters included in each of the above categories of the basic characters are defined as follows:
1. upper case letter
ÄBC~EFGH~JKLMN~PQRSTUVWXYZ
2. lower case letter
abcdefgh ijklmnopqrstuvwxyz
3. digit
4. special Character
-
()*+,-./:;<=>-I
Character
5. space
-
5.2 Lexical Elements, Separators, and Delimiters
The text of each compilation is a sequence of separate lexical elements. Esch lexical element is either an
identifier (which may be a reserved word), a literal, a comment, or a delimiter. The effect of a compilation
depends only on the particular sequences of lexical elements excluding the comments, if any, as described in
this chapter. Identifiers, literals, and comments are discussed in the following clauses. The remainder of this
clause discusses delimiters and separators.
An explicit separator is required to separate adjacent lexical elements when, without Separation, interpretation as
a Single lexical element is possible. A separator is any of a space Character, a format effector, or the end of a
Design Goals and Language Summary 7

line. A space Character is a separator except within a comment or a Character Iiteral. Format effectors other
than horizontal tabulation are always separators. Horizontal tabulation is a separator except within a comment.
The end of a line is always a separator. The language does not define what Causes the end of a line.
One or more separators are allowed between any two adjacent lexical elements, before the first lexical element
of each compilation, or after the last lexical element of each compilation.
At least one separator is required
between an identifier or a numeric literal and an adjacent identifier or numeric Iiteral.
A delimiter is one of the following special characters
()*+,-./:;c=>I
or one of the following compound delimiters each composed of two adjacent special characters
:= <> >= <=
=> . .
Esch of the special characters listed for Single Character delimiters is a Single delimiter except if that Character is
used as a Character of a compound delimiter, a comment, or a literal.
Esch lexical element shall fit on one line, since the end of a line is a separator. The Single quote and underscore
characters, as weil as two adjacent hyphens, are not delimiters, but may form part of other lexical elements.
5.3 Identifiers
identifier ::= SQL-actual identifier
-
The length restrictions that apply to SQL identifiers (see 5.2, Syntax rules 8, 9 and 5.5 Syntax rule 3 of ISO/IEC
-
9075:1992) do not apply to SAMeDL identifiers. Whenever two identifiers are deemed equivalent, it is in the
sense of the rules of SQL (see 5.2, Syntax rules 10 through 14 of ISO/IEC 9075:1992).
Note. An SQL_actual-identifier is either a delimited-identifier or a regularjdentifier. The form of an SQL regular-identifier is
essentially the same as the Ada identifier, except that a regular-identifier may end in an underscore. A delimited-identifier is any
Character string within a pair of doublequote characters ( “). Delimited identifiers provide a means of using tokens that would otherwise
be reserved words (see 5.6 of this specification) as identifiers. Thus fetch is a resetved word, but the construct
procedure "fetch" is fetch;
defines a procedure named “fetch” that contains a fetch Statement.
Identifier equivalence in SQL is similar to Ada identifier equivalence for regular identifiers. Equivalence for delimited identifiers is case
sensitive. Equivalence of regular identifiers with delimited identifiers proceeds by considering the regular identifier to be all upper case
and then doing a case sensitive comparison to the delimited identifier. So a column named Status is not identified by the delimited
identifier “Status” but is identified by the delimited identifier “STATUS ”. end Note
Ada Semantics
Let ident be an identifier. Define AdalD(ident) by
AdaID(ident) = ident if ident is a regular identifier
id if ident is the delimited identifier "id"
Note: If ident is an identifier, AdalD(ident) is not necessarily an Ada_identifier.
8 Database Programming Language - SAMeDL

o lSO/IEC
ISO/IEC 12227: 1995(E)
SQL Semantics
Let SQL,,,, be a function on identifiers into the set of SQL identifiers with the property that SQ&,,&d 1)
- -
and SQL NAME(Idb2) shall be equivalent if and only if Id-1 and ld-2 are equivalent (see above).
Note: Entry level SQL identifiers are limited to eighteen characters in length (see 5.2, leveling rule 2.a of ISO/IEC 90751992) but
SAMeDL identifiers are not. SQL,,,, deals with this discrepancy. SQL,,,, is not applied to externally visible names, i.e., Schema,
table, view and column names, but only to names within SQL modules, e.g., cursor, procedure and Parameter names.
5.4 Literals and Data Classes
Literals follow the SQL Iiteral Syntax (5.3 of ISO/IEC 9075:1992). There are five classes into which literals are
placed based on their lexical properties: Character, integer, fixed, float, and enumeration.
literal ::=
database literal 1 enumeration-literal
-
database literal ::=
-
1 1 [+ 1 -1 numeric-literal
Character-litera
numeric-literal ::=
integer-literal 1 fixed-literal 1 float-literal
Character-literal ::=
' {Character} '
Character ::=
implernen ta tion defined
integer-literal ::=
digit {digit}
fixed literal ::=
Gteger-literal integer-literal 1
integer-literai 1
integer-literal .
float literal ::=
f?xed-literal exp [+ 1 -1 integer-literal
exp ::=
e I E
.
enumeration-literal . . l = identifier
1. Esch literal has an associated data class, denoted DATACLASS(L). In particular:
if L is a Character-literal then DATACLASS(L) is Character
integer Iiteral integer
fixed likral f ixed
float literal f loat
enumeration literal enumeration
-
(see data-class in 7.1 .l .l of this specification).
2. If Id is an enumeration Iiteral, than AdalD(id) shall be an Ada identifier. In particular, an enumeration Iiteral
-
shall not be an Ada Character Iiteral.
Lexical Elements 9
3. Every Character-literal CL has an associated length LENGTH(CL) in the sense of 5.3, Syntax Rule 5 in
ISO/IEC 9075:1992. For any non Character literal, L, LENGTH(L)=NO LENGTH.
-
4. Integer, fixed and float Iiterals are collectively known as numeric literals. Every numeric Iiteral NL has a
scale, SCALE(NL). An integer Iiteral has scale 0. The scale of a float Iiteral is equal to the scale of any other
float Iiteral and larger than the scale of any non-float numeric Iiteral. The scale of a fixed Iiteral is the number
of digits appearing to the right of the decimal Point within the literal. Any non numeric literal, L, has
SCALE(L)=NO SCALE. See 6.4 of this specification for the interpretation of enumeration literals.
-
5. The Single quote or “tic” Character tan be included in a Character-literal by duplication in the usual way.
Thus the string of tics: r ’ ’ ’ represents a Character-literal of length one containing the Single quote as its
only Character.
5.5 Comments
A comment Starts with two adjacent hyphens and extends up to the end of the line. A comment tan appear on
any line of a module. The presence or absence of comments has no influence on whether a module is legal or
illegal. Furthermore, comments do not influence the meaning of a module; their sole purpose is the enlighten-
ment of the human reader.
5.6 Reserved Words
The following is the list of the SAMeDL reserved words:
ABSTRACT ALL AND AS ASC
AUTHORIZATION AVG BASE BETWEEN BODY BY
@LASS CLOSE COMMIT CONSTANT CONVERSION
CHECK
CURRENT CURSOR DATA DBMS DECLARE
COUNT
DEFINITION DELETE
DEFAULT DERIVED DESC DISTINCT
DOMAIN END ENUMERATION ESCAPE EXISTS EXCEPTION
FETCH FOR FOREIGN FROM GRANT
EXTENDED
IMAGE IN INSERT INTO
GROUP HAVING
1s KEY LIKE MAP MIN
NAMED NEW NOT NULL
MODULE NAME
OF ON OPEN OPTION OR ORDER
PATTERN POS PRIMARY PRIVILEGES PROCEDURE
OUT
RECORD REFERENCES ROLLBACK
PUBLIC RAISE SCALE
SCHEMA SELECT SET SOME STATUS SUBDOMAIN
TABLE TO TYPE UNION UNIQUE
SUM
UPDATE USE USER USES VALUES VIEW
WITH WORK
WHERE
6 Common Elements
10 Database Programming Language - SAMeDL

o ISO/IEC
6.1 Compilation Units
A compilation mit is the smallest syntactic Object that tan be successfully compiled. lt consists of a sequence of
one or more modules.
compilationunit ::=
module {module}
module ::=
definitional module abstract-module schemamodule
-
6.2 Context Clause
The context clause is a means by which a module gains visibility to names defined in other modules. The Syntax
and semantics of context clauses are similar to the Syntax and semantics of Ada context clauses (8.4, 10.1 .l of
ISO 86521987) but there are differentes.
context ::=
tontext-clause {tontext-clause}
tontext-clause ::=
with-clause 1 use-clause 1 with-schema-clause
with clause ::=
iith module-name [asshrase]
module-name [as_phrase]) ;
{ I
use-clause ::=
use module-name {, module name) ;
-
with-schema-clause ::=
withschema schema-name [asshrase]
schema-name [asshrase] } ;
{ I
module-name ::=
identifier
schema-name ::=
SQL-schema-authorization-identifier
as_phrase ::=
as identifier
1. Consider the following with clause and with Schema clause:
- - -
with M [as N,];
with Schema S [as N2];
In these clauses, M shall be the name of a definitional module and S the name of a Schema module. The
name M of the definitional module is said to be exposed if the as Phrase
is not present in the
-
tontext-clause; otherwise the name M is hidden and the name N, is the exposed name of M. Similar
The name of a module (see 7.1, 7.2, and 8.1 of this specification) is its
comments apply to S and N,.
exposed name within the text of that module. Within the text of any module, no two exposed module names
shall be the Same.
clause shall be the exposed name of a definitional-module that is an Operand of a
2. A module name in a use
Prior with Clause. -
-
Common Elements 11
o ISO/IEC
3. The scope of a with clause or use clause in the context of a module (see 7.1, 7.2, and 8.1 of this specifica-
tion) is the text of that module. -
4. Only an abstract or Schema module context may contain a with Schema clause.
- -
Note: As a consequence of these definitions, abstract modules cannot be brought into the context of (withed by) another module.
6.3 Table Names and the From Clause
The table names in insert, update, and delete Statements and the from clauses of select Statements, cursor
declarations, and subqueries (see 8.3, 8.4 and 8.12 of this specification) also make names, in particular column
names, visible. The from-clause differs from an SQL-from-clause (6.3 and 7.4 of ISO/IEC 9075:I 992) only in
the optional appearance of the as keyword, which is inserted for uniformity with the remainder of the language.
from clause ::=
Eorn table ref {, table ref}
- -
table-ref ::=
table-name [ [as] SQL-correlation-name]
table-name ::=
[Schema ref.]identifier
-
schema-ref ::=
schema-name 1 identifier
1. If present, Schema ref shall be either the Schema name in the authorization clause of the abstract module in
which the table name appears (8.1 of this specification) or the exposed name of a Schema module in the
-
context of the module in which table-name appears (6.2 of this specification). In either case, the identifier
shall be the name of a table or the name of a view within that Schema module. If the schema-ref is absent
from the table name, then the identifier shall be the name of a table or the name of a view within the Schema
-
module named in the authorization clause of the module in which the table-name appears.
2. If the correlation name is not present in a table ref, then the table name or view name in the table ref is
exposee otherwise the table name or view name is hidden and the correlation name is exposed. k two
-
exposed names within a from-clause shall be the Same.
3. For the scope of table and view names see Syntax Rule 2 of 6.3 in ISO/IEC 90751992.
6.4 References
The rules concerning the meaning of references are modeled on those of Ada and those of SQL. As neither
module nesting nor program name overloading occurs, these rules are fairly simple, and are therefore listed. For
the purposes of this clause, an item is either:
-- A definitional module (See 7.1), an abstract module (8.1), or a Schema module (7.2 of this specification).
-- A procedure (See 8.2), a cursor (8.4), or a procedure within a cursor (8.5 of this specification).
-- Anything in the syntactic category ‘definition’ as given by 7.1 of this specification. This includes base
domains, domains, subdomains, enumerations, constants, records, and Status maps.
12 Database Programming Language - SAMeDL

o lSO/IEC
-- A domain Parameter (See 7.1 .l .l of this specification.)
-- An enumeration Iiteral within an enumeration (See 5.4 and 7.1.6 of this specification).
-- An exception (7.1.7 of this specification).
-- An input-Parameter of a procedure or cursor declaration (See 8.2, 8.4, and 8.6 of this specification).
-- A table defined within a Schema module (See 7.2 of this specification).
-- A column defined within a table (See 7.2 of this specification).
A location within the text of a module is said to be a defining location if it is the place of
-- The name of an item within the item ’s declaration. (Note: This includes enumeration Iiterals within the decla-
ration of an enumeration and domain Parameters within the declaration of a domain.)
-- The name of a table in a from clause.
-
-- The name of the target table of an insert, update, or delete Statement.
-- A Schema name or module name in a context clause.
- - -
Text locations not within comments that are not defining locations are reference locations. An identifier that
appears at a reference location is a reference to an item. The meaning of that reference in that location, that is,
the identity of the item referenced, is defined by the rules of this clause. When these rules determine more than
one meaning for an identifier, then all items referenced shall be enumeration literals.
module-reference ::= identifier
schema-reference ::= schema-name 1 identifier
base domain reference ::= [module reference.]identifier
- - -
domain reference ::= [module reference.]identifier
- -
domainsarameter reference ::= domain reference.identifier
-
-
subdomain-reference ::= [module reference.]identifier
-
enumeration-reference ::= [module reference.]identifier
-
enumerationJiteral_reference ::=
[module reference.]identifier
-
exception-reference ::= [module reference.]identifier
-
constant-reference ::=
[module reference.]identifier
-
record-reference ::= [module reference.]identifier
-
procedure reference ::= [module reference.]identifier
- -
cursor-reference ::= [module reference.]identifier
-
cursorsroc-reference ::= [cursor reference.]identifier
-
Common Elements 13
input-reference ::= [procedure reference.]identifier
-
1 [cursor_proc-reference.]identifier
status-reference ::= [module reference.]identifier
-
table-reference ::= [Schema reference.]SQL identifier
- -
column-name ::= SQL-identifier
column-reference ::= [table-reference.]column-name
(See 6.4 of ISO/IEC 9075:1992).
A reference is a simple name (an identifier) optionally preceded by a prefix: a sequence of as many as three
identifiers, separated by dots.
For the purposes of this clause, the “text of a cursor” does not include the text of the procedures, if any,
contained in the cursor. A dereferencing rule is said to “determine a denotation” for a reference if it either (i)
specifies an item to which the reference refers, or (ii) determines that the reference is not valid.
Note: Unlike the Ada dereferencing rules (see 8.2 and 8.3 in ISO 8652:1987), the SAMeDL rules treat the prefix as a whole, not
component by component.
Prefix Denotations
The prefix of a reference shall denote one of the following:
-- An abstract module, procedure, cursor or cursor procedure, but only from within the text of the abstract
module, procedure, cursor, or cursor procedure.
-- A table, if the table is in scope at the location in which the reference appears.
-- A domain.
-- A definitional or Schema module.
Note: As a consequence of the rule given earlier, that all meanings of an identifier with multiple meanings must be enumeration literals,
a prefix may have at most one denotation or meaning, as it may not denote an enumeration literal.
Let L be the reference location of prefix P. Let X, Y, and Zbe simple names. Then
1. If L is within the text of a cursor procedure U, then P denotes
a. The cursor procedure U if either
i. P is of the form Xand X is the simple name of U; or
ii. P is of the form X. Y; X is the name of the cursor containing L (and therefore also U); in which case Y
shall be the simple name of U else the prefix is not valid; or
iii. P is of the form X.Y.Z X is the name of the module containing L; Y is the name of the cursor
containing L (and therefore also U); in which case Z shall be the simple name of U else the prefix is
not valid;
b. The table T being updated in a cursor update Statement, if the Statement within the cursor procedure
containing L is a cursor-update-Statement and either
14 Database Programming Language - SAMeDL

o ISO/IEC
i. P is of the form Xand X is the simple name of T; or
ii. P is of the form X. Y; X is an exposed name for the Schema module S containing the declaration of T
and Y is the simple name of T.
2. If rule 1 does not determine a denotation for P, then P denotes
a. The cursor or procedure R, if L is within the text of ß and either
i. P is of the form Xand X is the simple name of ß; or
ii. P is of the form X. Y, X is the name of the module containing L (and therefore also ß); Y is the simple
name of ß;
b. The table T, if L is in the scope of table name T(Rule 3 in 6.3 of this specification), and either
i. P is of the form Xand X is a simple name exposed for T; or
ii. P is of the form X. Y; X is the exposed of the module containing the table Tand Yis a
simple name of T.
3. If rules 1 and 2 do not determine a denotation for P, then Pdenotes the domain ß,
a. If P is of the form X and X is the simple name of ß and the declaration of ß appears in the module
containing L and precedes L within that module; or
b. P is of the form X. Y; X is the exposed name of the module containing the declaration of R and Y is the
simple name of ß.
4. If none of the above rules determines a denotation for P, then P is a simple name that denotes the
a. Definitional module M if either
i. L is in the scope of a with clause exposing Pas the name of M; or
-
ii. L is in the definitional module IM and P is the name of M.
Schema module S if
b .
i. L is in the scope of a with-schema-clause exposing Pas the name of S; or
ii. L is in an abstract module whose authorization clause identifies S and P is the name of S;
c. Abstract module M if L is within the text of M and P is the name of M;
d. Domain 0, if D is declared within a module N such that there is a use clause for N in the module
containing L, and P is the name of D.
Common Elements 15
Denotations of Full Names
Let L be the location of a reference Id. Then Id is a reference to the item Im if Im is not a module, procedure,
cursor or cursor procedure, or table and
1. Id is of the form P.X where X is the name of Im and P is a prefix denoting
a. A definitional module containing the declaration of Im;
b. The abstract module, M, in which L appears, and Im is declared in M at a text location that precedes L;
C. The procedure, cursor, or cursor procedu re that contains L, and Im is an input para to that
procedure, cursor, or CU rsor procedure;
d. A table, in which case Im is a column within that table;
e. A Schema module, in which case Im is a table within that module.
f. A domain, in which case Im is a Parameter in that domain.
2. Id is of the form Xand X is the name of Im. Then
a. L appears in a cursor, procedure, or cursor procedure (See 8.4, 8.2, and 8.5 of this specification) and
i. Im is an input Parameter to that cursor, procedure, or cursor procedure;
ii. Im is a column of one of the tables in scope of L;
. If rule (a) does not determine a denotation for Id, then Im is declared in the module containing L at a
b
location preceding L;
c. If neither rule (a) nor (b) determines a denotation for
...