ISO/IEC 9075:1992/Cor 3:1999

Information technology - Database languages - SQL - Technical Corrigendum 3

Technologies de l'information — Langages de base de données — SQL — Rectificatif technique 3

General Information

• Status: Withdrawn
• Publication Date: 08-Dec-1999
• Withdrawal Date: 08-Dec-1999
• ICS: 35.060 - Languages used in information technology
• Technical Committee: ISO/IEC JTC 1/SC 32 - Data management and interchange
• Drafting Committee: ISO/IEC JTC 1/SC 32/WG 3 - Database language
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 16-Dec-1999
• Completion Date: 30-Oct-2025

Relations

• Corrects: ISO/IEC 9075:1992 - Information technology - Database languages - SQL
• Effective Date: 06-Jun-2022
• Revised: ISO/IEC 9075-4:1999 - Information technology - Database languages - SQL - Part 4: Persistent Stored Modules (SQL/PSM)
• Effective Date: 16-Oct-2025
• Revised: ISO/IEC 9075-5:1999 - Information technology - Database languages - SQL - Part 5: Host Language Bindings (SQL/Bindings)
• Effective Date: 16-Oct-2025
• Revised: ISO/IEC 9075-1:1999 - Information technology - Database languages - SQL - Part 1: Framework (SQL/Framework)
• Effective Date: 16-Oct-2025
• Revised: ISO/IEC 9075-2:1999 - Information technology - Database languages - SQL - Part 2: Foundation (SQL/Foundation)
• Effective Date: 16-Oct-2025
• Revised: ISO/IEC 9075-3:1999 - Information technology - Database languages - SQL - Part 3: Call-Level Interface (SQL/CLI)
• Effective Date: 16-Oct-2025
• Child: ISO/IEC 9075:1992 - Information technology - Database languages - SQL
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL STANDARD ISO/IEC 9075:1992
Technical Corrigendum 3
ISO/IEC 9075-3:1995
Technical Corrigendum 1
ISO/IEC 9075-4:1996
Technical Corrigendum 1
TECHNICAL CORRIGENDUM
Published 1999-11-15
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION � МЕЖДУНАРОДНАЯОРГАНИЗАЦИЯПОСТАНДАРТИЗАЦИИ � ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION � МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОМИССИЯ � COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
Information technology — Database languages — SQL
TECHNICAL CORRIGENDUM
Technologies de l'information — Languages de base de données — SQL
RECTIFICATIF TECHNIQUE
Technical Corrigendum 3 to International Standard ISO/IEC 9075:1992, Technical Corrigendum 1 to International
Standard ISO/IEC 9075-3:1995 and Technical Corrigendum 1 to International Standard ISO/IEC 9075-4:1996 were
prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 32, Data
management services.
Relation to previous technical corrigenda:
This Corrigendum contains the cumulative set of corrections to ISO/IEC 9075:1992, ISO/IEC 9075-3:1995 and
ISO/IEC 9075-4:1996.
It completely subsumes and replaces all previous corrigenda for ISO/IEC 9075.
Statement of purpose for rationale:
A statement indicating the rationale for each change to ISO/IEC 9075 is included. This is to inform the users of
that standard as to the reason why it was judged necessary to change the original wording. In many cases the
reason is editorial or to clarify the wording; in some cases it is to correct an error or an omission in the original
wording.
Notes on rule numbering:
This Corrigendum introduces some new Syntax, Access, General and Leveling Rules. The new Rules in this
Corrigendum have been numbered as follows:
Rules inserted between, for example, Rules 7) and 8) (in ISO/IEC 9075:1992) are numbered 7.1), 7.2), etc. [or
7) a.1), 7) a.2), etc.]. Those inserted before Rule 1) are numbered 0.1), 0.2), etc.
ICS 35.060 Ref. No. ISO/IEC 9075/Cor:1999(E)
© ISO/IEC 1999 – All rights reserved
Printed in Switzerland
ISO/IEC 9075/Cor:1999(E) ©ISO/IEC
Contents Page
ISO/IEC 9075:1992
Database Languages - SQL
.................................................................................... 7
Introduction . 7
2 Normative references . 7
3.3.4.3 Terms denoting rule requirements . 8
4.2 Character strings . 8
4.2.1 Character strings and collating sequences . 8
4.2.3 Rules determining collating sequence usage . 9
4.3.1 Bit string comparison and assignment . 9
4.4 Numbers . 9
4.4.1 Characteristics of numbers . 9
4.5 Datetimes and intervals . 10
4.5.1 Datetimes . 10
4.5.2 Intervals . 11
4.5.3 Operations involving datetimes and intervals . 11
4.6 Type conversion and mixing of data types . 12
4.8 Columns . 12
4.9 Tables . 12
4.10.2 Table constraints . 13
4.18.1 Status parameters . 13
4.21 Cursors . 13
4.22.6 SQL-statements and transaction states . 14
4.24 SQL dynamic statements . 14
4.26 Privileges . 14
4.28 SQL-transactions . 14
4.29 SQL-connections . 14
4.31 Client-server operation . 15
5.2 and . 15
5.3 . 16
5.4 Names and identifiers . 17
6.1 . 17
6.2 and . 18
6.3 . 18
6.4 . 19
6.5 . 20
6.6 . 20
6.7 . 21
6.8 . 21
6.10 . 22
6.11 . 25
6.12 . 25
6.14 . 25
6.15 . 27
7.1 . 28
7.4 . 29
7.5 . 30
7.6 . 31
7.7 . 31
7.8 . 32
7.9 . 33
7.10 . 35
7.11 , , and

. 36
©ISO/IEC ISO/IEC 9075/Cor:1999(E)
8 . 2 < c omp a r isio n p r e d ic ate> . . 36
8 . 3 < b etwe en p r e d ic ate> . . 36
8 . 7 < q uantifie d c omp a r iso n p r e d ic ate> . . 37
8 . 1 1 < o ve r la p s p r e d ic ate> . . 37
9 . 1 Retr ieval assignment . . 37
9 . 2 Sto r e assignment . . 38
9 . 3 Set o p e r atio n r esult d ata typ es . . 39
1 0 . 1 . . 40
10.2 , Table 16 . 41
1 0 . 4 < cha r a cte r set sp e cific atio n> . . 41
1 0 . 5 < c o llate clause> . . 41
10.6 and . 41
11.1 . 42
1 1 . 2 < d r o p schema statement> . . 42
11.4 . 42
1 1 . 5 < d efault clause> . . 42
11.6 . 44
11.8 . 45
11.9 . 45
11.11 . 45
11.15 . 46
11.16 . 47
11.17 . 47
1 1 . 1 8 < d r o p ta b le statement> . . 48
11.19 . 48
11.21 . 49
11.25 . 49
11.26 . 50
1 1 . 2 7 < d r o p d omain statement> . . 50
11.28 . 50
1 1 . 2 9 < d r o p cha r a cte r set statement> . . 51
11.30 . 51
1 1 . 3 1 < d r o p c o llatio n statement> . . 51
11.32 . 52
11.34 . 53
1 1 . 3 6 . . 53
1 1 . 3 7 < r evo ke statement> . . 55
1 2 . 3 < p r o c e d ur e> . . 60
1 2 . 4 Calls to a < p r o c e d ur e> . . 61
1 2 . 5 . . 71
1 3 . 1 < d e cla r e cur so r> . . 72
1 3 . 2 < o p en statement> . . 72
1 3 . 3 . . 72
1 3 . 4 < clo se statement> . . 73
1 3 . 5 . . 73
13.6 . 74
1 3 . 7 < d ele te statement: se a r che d> . . 74
1 3 . 8 . . 74
13.9 . 75
1 3 . 1 0 . . 75
1 3 . 1 1 . . 76
1 4 . 1 . . 76
1 4 . 2 . . 76
1 4 . 3 < c ommit statement> . . 76
ISO/IEC 9075/Cor:1999(E) ©ISO/IEC
15.1 . 76
15.2 . 77
15.3 . 77
16.5 . 77
17.1 Description of SQL item descriptor areas . 77
17.2 . 77
17.3 . 78
17.4 . 78
17.5 . 78
17.6 . 78
17.9 . 82
17.10 . 82
17.11 . 82
17.15 . 83
17.18 . 83
17.19 . 83
17.20 . 84
18.1 . 84
19.1 . 86
19.3 . 86
19.5 . 86
20.1 . 86
21.1 Introduction . 87
21.2.2 INFORMATION_SCHEMA_CATALOG_NAME base table . 87
21.2.3 INFORMATION_SCHEMA_CATALOG_NAME_CARDINALITY assertion . 88
21.2.4 SCHEMATA view . 88
21.2.5 DOMAINS view . 88
21.2.6 DOMAIN_CONSTRAINTS view . 88
21.2.9 COLUMNS view . 89
21.2.17 ASSERTIONS view . 89
21.2.23 CONSTRAINT_TABLE_USAGE view . 89
21.2.24 CONSTRAINT_COLUMN_USAGE view . 90
21.2.27 SQL_IDENTIFIER domain . 91
21.3.5 DATA_TYPE_DESCRIPTOR base table . 91
21.3.6 DOMAINS base table . 94
21.3.8 TABLES base table . 94
21.3.10 COLUMNS base table . 95
21.3.11 VIEW_TABLE_USAGE base table . 96
21.3.12 VIEW_COLUMN_USAGE base table . 96
21.3.13 TABLE_CONSTRAINTS base table . 97
21.3.15 REFERENTIAL_CONSTRAINTS base table . 97
21.3.17 CHECK_TABLE_USAGE base table . 97
21.3.18 CHECK_COLUMN_USAGE base table. 98
21.3.21 COLUMN_PRIVILEGES base table . 98
21.3.22 USAGE_PRIVILEGES base table . 99
21.3.23 CHARACTER_SETS base table . 99
21.3.24 COLLATIONS base table . 99
21.3.25 TRANSLATIONS base table . 99
21.3.26 SQL_LANGUAGES base table . 100
22.1 SQLSTATE . 100
22.2 SQLCODE . 102
22.3 Remote Database Access SQLSTATE Subclasses . 102
23.2 Claims of Conformance . 104
23.3 Extensions and options . 105
A.1 Intermediate SQL Specifications . 105
©ISO/IEC ISO/IEC 9075/Cor:1999(E)
A.2 Entry SQL Specifications . 107
Annex B: Implementation-defined elements . 110
Annex C Implementation-dependent elements . 111
Annex E Incompatibilities with ISO/IEC 9075:1989 . 112
Annex F Maintenance and interpretation of SQL . 113
ISO/IEC 9075-3:1995
Database Languages - SQL-Part 3:Call-Level Interface
(SQL/CLI)
.................................................................................. 115
Contents . 115
4.1 Introduction . 116
4.3 Diagnostics areas . 116
4.4.7 CLI descriptor areas . 116
5.1 . 116
5.2 invocation . 117
5.3 SQL/CLI common elements . 117
5.3.3 Implicit using clause . 118
5.3.4 Character string retrieval . 122
5.3.7 CLI-specific status codes . 122
5.3.8 Description of CLI item descriptor areas . 122
5.3.9 . 124
5.4 Data type correspondences . 125
6.4 AllocStmt . 125
6.5 BindCol . 126
6.6 BindParam . 126
6.9 ColAttribute . 128
6.13 DescribeCol . 128
6.17 ExecDirect . 128
6.18 Execute . 128
6.24 FreeStmt . 129
6.27 GetData . 129
6.30 GetDiagField . 129
6.31 GetDiagRec . 131
6.34 GetInfo . 132
6.34.1 GetParamData . 133
6.36 Get TypeInfo . 137
6.38 ParamData . 138
6.39 Prepare . 139
6.40 PutData . 139
6.41 RowCount . 139
6.38 ParamData . 140
6.42 SetConnectAttr . 140
6.43 SetCursorName . 140
6.44 SetDescField . 141
6.45 SetDescRec . 143
A.1 C Header File SQLCLI.H . 143
A.2 COBOL Library Item SQLCLI . 148
B.1 Create table, insert, select . 150
B.2 Interactive Query . 152
B.3 Providing long dynamic arguments at Execute() time . 153
Annex C . 154
Annex D Implementation-dependent elements . 154
Index . 154
ISO/IEC 9075/Cor:1999(E) ©ISO/IEC
ISO/IEC 9075-4:1996
Database Languages - SQL-Part 4:Persistent Stored Modules
(SQL/PSM)
.................................................................................. 155
2 Normative references . 155
3.3 Conventions . 155
6.2 . 155
6.3 . 155
6.6 . 156
7.3 . 156
9.1 . 157
10.3 . 157
10.7 . 158
10.4 . 158
10.8 . 158
10.9 . 158
10.13 . 159
10.16 . 159
10.18 . 159
10.20 . 159
10.21 . 160
11.4 . 162
12.2 . 162
13.2 . 163
13.3 . 163
13.9 . 163
13.14 . 163
17.3 . 164
19.1.5 ROUTINES view . 164
19.2.4 ROUTINES base table. 165
Annex A . 165
Annex B . 167
©ISO/IEC ISO/IEC 9075/Cor:1999(E)
ISO/IEC 9075:1992
Database Languages - SQL
Introduction
1. Rationale: In the list of significant new features, the wording incorrectly implies that all the examples
listed in item 10) are referential integrity facilities.
On page xiv, in Significant new feature 10), replace "referential integrity" with "integrity".
2 Normative references
1. Rationale: Editorial. The (non-extended) Pascal standard should be identified as ISO/IEC 7185 rather
than ISO 7185. The designation was changed in 1990 when the standard was revised.
Change "ISO 7185:1990" to "ISO/IEC 7185:1990"
2. Rationale: Editorial.
Add the following reference after the reference to "ISO 8601:1988":
— ISO 8649:1988, Information Processing Systems — Open Systems Interconnection — Service
Definition for the Association Control Service Element.
3. Rationale: The newly revised Ada language standard (ISO/IEC-8652:1995, Information technology —
Programming languages — Ada) contains support for decimal-encoded numeric data and variable length
character strings. The revised interface allows newly written applications in the revised Ada language
access to these features of SQL; previously written Ada applications, conformant with the earlier Ada
interface, are conformant with the revised interface.
Replace the reference to ISO/IEC 8652:1987) with:
— ISO/IEC 8652:1995, Information technology — Programming languages — Ada.
4. Rationale: Editorial.
Add the following reference after the reference to ISO/IEC 8824:1990:
— ISO/IEC 9579-1:1993, Information technology — Open Systems Interconnection — Remote
Database Access, Part 1: Generic Model, Service, and Protocol.
Add the following reference after the reference to ISO/IEC 9899:
— ISO/IEC 10026-21, Information technology — Open Systems Interconnection — Distributed
Transaction Processing — Part 2: Service Definition.
ISO/IEC 9075/Cor:1999(E) ©ISO/IEC
3.3.4.3 Terms denoting rule requirements
1. Rationale: The following unifies the SQLSTATE returned for the different ways of invoking an SQL
statement.
In the first and second paragraphs, replace "syntax error or access rule violation (if this situation occurs during
dynamic execution of an SQL-statement, then the exception that is raised is syntax error or access rule violation
in dynamic SQL statement; if the situation occurs during direct invocation of an SQL-statement, then the
exception that is raised is syntax or access rule violation in direct SQL statement)" with "syntax error or access
rule violation".
4.2 Character strings
1. Rationale: Editorial.
In the second paragraph, replace the last sentence with:
Character sets defined by standards or by implementations reside in the Information Schema (named
INFORMATION_SCHEMA) in each catalog, as do collations and translations defined by standards and
collations, translations, and form-of-use conversions defined by implementations.
4.2.1 Character strings and collating sequences
1. Rationale: The following changes make the definitions of character set and collation descriptors more
precise.
Replace the text on page 17 that occurs after the first paragraph with:
A character set is described by a character set descriptor. A character set descriptor includes:
— the name of the character set or character repertoire,
— if the character set is a character repertoire, then the name of the form-of-use,
— an indication of what characters are in the character set, and
— whether or not the character set uses the DEFAULT collation for its character repertoire, and,
— if the character set does not utilize the DEFAULT collation for its character repertoire, then the
contained in the character set's , if any, the name> contained in the character set's or , if any, and,
whether or not DESC was specified in the reference to the collation
For every character set, there is at least one collation. A collation is described by a collation descriptor. A
collation descriptor includes:
— the name of the collation,
— the name of the character repertoire on which the collation operates,
— whether the collation has the NO PAD or the PAD SPACE attribute, and
— whether or not this collation utilizes the DEFAULT collation for its character repertoire,
©ISO/IEC ISO/IEC 9075/Cor:1999(E)
— if the collation does not utilize the DEFAULT collation for its character repertoire, then the
contained in the collation's , if any, the
contained in the collation's , if any, and whether or not DESC was specified in the
definition of the collation.
4.2.3 Rules determining collating sequence usage
1. Rationale: Editorial. The second bullet of the first paragraph (When columns are involved (e.g.,
comparing .)) predicates the possibility of just one column being involved, but the sentence ends with
words that imply at least two columns. In addition, it is not clear whether the intent is that default collating
sequence of a column overrides the collating sequence (necessarily the default for the relevant repertoire)
for a literal.
Replace the second bullet with:
— When one or more columns are involved (e.g., comparing two columns, or comparing a column to a
literal), then provided that all columns involved have the same default collating sequence and there is
no explicit specification of a collating sequence, that default collating sequence is used.
4.3.1 Bit string comparison and assignment
1. Rationale: The second paragraph can be read to mean that all source bits are assigned successively to the
most significant bit position of the receiving (target) string. Note that there does not appear to be a
corresponding rule for character string assignment in the relevant subclause of "Concepts". Relevant rules
do exist in clause 9, but do not address the order in which bits (or characters) are assigned.
Delete the second paragraph of the subclause.
4.4 Numbers
1. Rationale: Clarification.
Add the following sentence immediately before the heading of Subclause 4.4.1 Characteristics of Numbers:
A value described by a numeric data type descriptor is always signed.
4.4.1 Characteristics of numbers
1. Rationale: In several paragraphs in this subclause, phrases similar to "values representable in the data
type" are used when the meaning is "members of the data type". A data type is defined as a set of values, so
the term is unnecessarily complicated. Since there are rules defining mappings from all numbers within the
range of a data type onto that data type, the meaning of "representable" is anyway somewhat ambiguous.
Simpify the convoluted wording used to specify that rounding is always towards zero. Use numeric instead
of numerical for consistency.
Replace the fourth, fifth, sixth, seventh and eighth paragraphs with:
An approximation obtained by truncation of a numeric value N for an T is a value V in
T such that N is not closer to zero than is V and there is no value in T between V and N.
An approximation obtained by rounding of a numeric value N for an T is a value V in
T such that the absolute value of the difference between N and the numeric value of V is not greater than half
ISO/IEC 9075/Cor:1999(E) ©ISO/IEC
the absolute value of the difference between two successive numeric values in T. If there are more than one
such values V, then it is implementation-defined which one is taken.
All numeric values between the smallest and the largest value, inclusive, in a given exact numeric type have
an approximation obtained by rounding or truncation for that type; it is implementation-defined which other
numeric values have such approximations.
An approximation obtained by truncation or rounding of a numeric value N for an type> T is a value V in T such that there is no value in T that lies between the V and N.
If there are more than one such values V then it is implementation-defined which one is taken. It is
implementation-defined which numeric values have approximations obtained by rounding or truncation for a
given approximate numeric type.
4.5 Datetimes and intervals
1. Rationale: Clarification.
Add the following sentence before the paragraph starting "Every datetime .":
A value described by an interval data type descriptor is always signed.
4.5.1 Datetimes
1. Rationale: Editorial.
Replace the first paragraph with:
Table 4, "Fields in datetime items", specifies the fields that can make up a datetime value; a datetime value is
made up of a subset of those fields. Not all of the fields shown are required to be in the subset, but every
field that appears in the table between the first included primary field and the last included primary field shall
also be included. If either timezone field is in the subset, then both of them shall be included.
2. Rationale: Clarify the treatment of time zones.
Replace the sixth, seventh, eighth and ninth paragraphs with:
A datetime data type that specifies WITH TIME ZONE is a data type that is datetime with time zone.
The surface of the earth is divided into zones, called time zones, in which every correct clock tells the same
time, known as local time. Local time is equal to UTC (Coordinated Universal Time) plus the time zone
displacement, which is a value of INTERVAL HOUR TO MINUTE, between -'12:59' and +'13:00'. The time
zone displacement is constant throughout a time zone, changing at the beginning and end of Daylight Saving
Time, where applicable.
A datetime value, of data type TIME or TIMESTAMP, may represent a local time or UTC. A data item may
be defined to contain either a datetime value only, or a datetime value together with a time zone
displacement.
For the convenience of users, whenever a datetime value with time zone is to be implicitly derived from one
without (for example, in a simple assignment operation), SQL assumes the value without time zone to be
local, subtracts the default session time zone displacement from it to give UTC, and associates that time zone
displacement with the result.
©ISO/IEC ISO/IEC 9075/Cor:1999(E)
Conversely, whenever a datetime value without time zone is to be implicitly derived from one with, SQL
assumes the value with time zone to be UTC, adds the time zone displacement to it to give local, and the
result, without any time zone displacement, is local.
4.5.2 Intervals
1. Rationale: Editorial
Replace the fifth paragraph with:
Within an item of type interval, the first field is constrained only by the of
the associated . Table 7, "Valid values for fields in INTERVAL items", specifies the
constraints on subsequent field values.
2. Rationale: Editorial.
In Table 7, replace "" (two
occurrences).
3. Rationale: Clarify the precision of interval fields.
Replace the sixth paragraph (that following Table 7) with:
Values in interval fields other than SECOND are integers, and have precision 2 when not the first field.
SECOND, however, can be defined to have an that indicates the
number of decimal digits maintained following the decimal point in the seconds value. When not the first
field, SECOND has a precision of 2 places before the decimal point.
4. Rationale: The wording seemed to imply that extra fields effectively added to a day-time interval for the
purposes of operations between two fields are all added at the same end. However, comparison of an
HOUR interval with a DAY-MINUTE interval would require extension of the HOUR interval at both ends.
In the ninth paragraph, change "either the most significant end or the least significant end of one or both day-
time intervals" to "either the most significant end of one interval, or the least significant end of one interval, or
both".
4.5.3 Operations involving datetimes and intervals
1. Rationale: Editorial. Table 8, Valid operators involving datetimes and intervals, specifies not the results of
arithmetic operations involving datetime and interval operands, but the result types of operations between
operands of those types.
Replace the first paragraph with:
Table 8, "Valid operators involving datetimes and intervals", specifies the data types of the results of
arithmetic operations involving datetime and interval operands.
ISO/IEC 9075/Cor:1999(E) ©ISO/IEC
4.6 Type conversion and mixing of data types
1. Rationale: Correct an inconsistency in style between the third sentence of the third paragraph and similar
statements elsewhere in the standard.Also correct the grammar of the last sentence.
Replace the third paragraph with:
Values corresponding to the data types BIT and BIT VARYING are always mutually comparable and are
mutually assignable. If a store assignment would result in the loss of bits due to truncation, then an exception
condition is raised. When values of unequal length are compared, if the shorter is a prefix of the longer, then
the shorter is less than the longer; otherwise, the longer is effectively truncated to the length of the shorter for
the purposes of comparison. When values of equal length are to be compared, then a bit-by-bit comparison is
made. A 0-bit is less than a 1-bit.
4.8 Columns
1. Rationale: Editorial.
Replace the third paragraph and the lead-in to the bullet list of the fourth paragraph with:
Every column has a nullability characteristic that indicates whether any attempt to store a null value into that
column will inevitably cause an exception condition to be raised, and whether any attempt to retrieve a value
from that column can ever result in a null value. The possible values of the nullability characteristic are
known not nullable and possibly nullable.
A column C with CN of a base table T has a nullability characteristic that is known not
nullable if any only if either:
2. Rationale: Editorial.
In the penultimate paragraph on page 28, replace "" with " constructor element>".
4.9 Tables
1. Rationale: Editorial.
Replace the first sentence of the third paragraph with:
A table is either a base table or a derived table.
2. Rationale: There is no named derived table other than a viewed table.
After the paragraph that begins with "A derived table descriptor describes a derived table.", delete the first item
("— if the table is named, then the name of the table;").
3. Rationale: There is no named derived table other than a viewed table.
After the paragraph that begins with "A view descriptor describes a view.", insert "— the name of the view, and"
before the existing item.
©ISO/IEC ISO/IEC 9075/Cor:1999(E)
4.10.2 Table constraints
1. Rationale: Editorial.
In the Note, replace "" with "".
2. Rationale: Editorial.
In the paragraph that begins with "A referential constraint is satisfied", replace "" with " type>".
4.18.1 Status parameters
1. Rationale: To insure that the value returned to the user in SQLSTATE is representative of the actual state
of the transaction or SQL-statement.
Add the following as the last paragraph:
For the purpose of choosing status parameter values to be returned, exceptions for transaction rollback have
precedence over exceptions for statement failure. Similarly, completion condition no data has precedence
over warning, which has precedence over successful completion. All exceptions have precedence over all
completion conditions. The values assigned to SQLSTATE shall obey these precedence rules.
4.21 Cursors
1. Rationale: Define "dynamic cursor" and "extended dynamic cursor".
Add the following after the first sentence of the first paragraph:
A cursor specified by a is a declared dynamic cursor. A cursor specified by an
is an extended dynamic cursor. A dynamic cursor is either a declared dynamic
cursor or an extended dynamic cursor.
2. Rationale: Correct concepts section regarding when cursors are destroyed.
Replace the second paragraph with:
For every or in a , a cursor is effectively created when
an SQL-transaction (see Subclause 4.28, "SQL-transactions") referencing the is initiated, and
destroyed when that SQL-transaction is terminated. An extended dynamic cursor is effectively created when
an is executed within an SQL-transaction and destroyed when that SQL-
transaction is terminated. In addition, a dynamic cursor is destroyed when a
is executed that deallocates the prepared statement on which the cursor is based.
ISO/IEC 9075/Cor:1999(E) ©ISO/IEC
4.22.6 SQL-statements and transaction states
1. Rationale: No statement can be both transaction-initiating and not transaction-initiating.
In the first dashed list (of transaction-initiating SQL-statements), in the bulleted sublist of SQL-data statements,
delete the entry for .
4.24 SQL dynamic statements
1. Rationale: Editorial.
In the fourth paragraph, replace "s" with "s".
2. Rationale: Editorial.
In the eighth paragraph, replace the first occurrence of "s" with " statement>s", and replace the second occurrence of "s" with "s".
4.26 Privileges
1. Rationale: Editorial.
In the fourth paragraph on page 52, replace " is" with " identifier> is".
2. Rationale: Provide missing rules that cover the acquisition of the necessary privileges to acquire the WITH
GRANT OPTION on views through a grant to PUBLIC.
Add the following before the antepenultimate paragraph of this Subclause:
The phrase user privileges refers to the set of privileges defined by the privilege descriptors whose grantee is
either the identified or PUBLIC.
4.28 SQL-transactions
1. Rationale: Clarification.
In the paragraph that begins "In some environments (e.g., remote database access)", replace all occurrences of
"SQL-environment" with "SQL-implementation".
4.29 SQL-connections
1. Rationale: Editorial.
Replace the second paragraph with :
An SQL-connection is an active SQL-connection if any SQL-statement that initiates or requires an SQL-
transaction has been executed at its SQL-server via that SQL-connection during the current SQL-transaction.
©ISO/IEC ISO/IEC 9075/Cor:1999(E)
2. Rationale: Clarification.
In the last sentence of the penultimate paragraph, replace "SQL-environment" with "SQL-implementation".
4.31 Client-server operation
1. Rationale: Clarification.
Replace the first sentence with :
As perceived by an SQL-agent, an SQL-implementation consists of one or more SQL-servers and one SQL-
client through which SQL-connections can be made to them.
5.2 and
1. Rationale: The maximum length of an is intended to be 128 characters.
Replace Syntax Rule 8) with :
8) In a , the number of s plus the number of s shall be
less than 128.
2. Rationale: A shall not contain any or . Thus, a identifier> with a containing a or ...