SQL/Temporal

WG3:YGJ-016 X3H2-99-084 March, 1999

ISO International Organization for Standardization

ANSI American National Standards Institute

ANSI TC X3H2 ISO/IEC JTC 1/SC 21/WG 3 Database

Title: (ISO Working Draft) Temporal (SQL/Temporal) Author: Jim Melton (Editor) References: 1) ANSI X3H2-99-078/WG3:YGJ-010, (ANSI/ISO Working Draft) Framework (SQL/Framework), March, 1999 2) ANSI X3H2-99-079/WG3:YGJ-011, (ANSI/ISO Working Draft) Foundation (SQL/Foundation), March, 1999 3) ANSI X3H2-99-080/WG3:YGJ-012, (ANSI/ISO Working Draft) Call-Level Interface (SQL/CLI), March, 1999 4) ANSI X3H2-99-081/WG3:YGJ-013, (ANSI/ISO Working Draft) Persistent Stored Modules (SQL/PSM), March, 1999 5) ANSI X3H2-99-082/WG3:YGJ-014, (ANSI/ISO Working Draft) Host Language Bindings (SQL/Bindings), March, 1999 6) ANSI X3H2-99-083/WG3:YGJ-015, (ANSI/ISO Working Draft) XA Specialization (SQL/Transaction), March, 1999 7) ANSI X3H2-99-084/WG3:YGJ-016, (ANSI/ISO Working Draft) Temporal (SQL/Temporal), March, 1999 8) ANSI X3H2-99-085/WG3:YGJ-017, (ANSI/ISO Working Draft) Management of External Data (SQL/MED), March, 1999

9) ANSI X3H2-99-086/WG3:YGJ-018, (ANSI/ISO Working Draft) Object Language Bindings (SQL/OLB), March, 1999

2

1 Possible problems with SQL/Temporal I observe some possible problems with SQL/Temporal as defined in this document. These are noted below. Further contributions to this list are welcome. Deletions from the list (resulting from change proposals that correct the problems or from research indicating that the problems do not, in fact, exist) are even more welcome. Other comments may appear in the same list. Because of the highly dynamic nature of this list (problems being removed because they are solved, new problems being added), it has become rather confusing to have the problem numbers automatically assigned by the document production facility. In order to reduce this confusion, I have instead assigned "fixed" numbers to each possible problem. These numbers will not change from printing to printing, but will instead develop "gaps" between numbers as problems are solved.

Possible problems related to SQL/Temporal Significant Possible Problems: 999 In the body of the Working Draft, I have occasionally highlighted a point that requires urgent attention thus: **Editor’s Note** Text of the problem. These items are indexed under "**Editor’s Note**". TMPRL-013 Discussion of Paper X3H2-95-429/DBL:LHR-043 noted the following Possible Problem: What is the implied length of a period? In what units is it expressed? How is it used? Does the current definition imply an implementation? TMPRL-014 During discussion of Paper X3H2-95-486/DBL:LHR-092, point 16, Steve Cannan noted the following Possible Problem: Amendments to various tables in SQL/Temporal to augment corresponding tables in SQL/Bindings for PERIOD needs to reflect the fact that PERIOD is a data type generator and not a predefined data type. TMPRL-015 During discussion of Paper Mike Sykes noted the following Possible Problem: The text of Clause 11, "Dynamic SQL", is appropriate only for so long as TIMESTAMP is the only permitted element type of a period type, and arguably not even that. However, there is at present no established way, in Dynamic SQL (in SQL/Bindings) or in CLI, of dealing with any data type that has parts: although SQL/Bindings Table 4, "Codes used for SQL data types in Dynamic SQL", has an entry for "Abstract data types", there is no entry for row types or for any collection type. Nor is there any indication of how the attributes, fields and elements, respectively, of these types are to be dealt with. When this problem has been solved, there will be a helpful precedent for the treatment of period types. In the meantime, using existing facilities, a value of a period type can be dealt with as the pair of values representing its respective beginning and ending bounds.

Possible problems with SQL/Temporal

Notes–1

Editor’s Notes for DBL:YGJ-016 and X3H2-99-084

TMPRL-015 During discussion of Paper DBL:MCI-044/X3H2-96-180, Paul Cotton noted the following Possible Problem: DBL:MCI-044/X3H2-96-180 added support for additional data types to the SQL/Temporal PERIOD data type. This proposal and the current SQL/Temporal base document do not currently define the "length" of a PERIOD data type as is defined for other data types (consider SQL/Foundation, Subclause 6.1, "", Syntax Rule 33: "The length of a DATE is 10 positions."). SQL/CLI uses the definition of the "length" of datetime types to define the DescribeCol ColumnSize output parameter (SQL/CLI, Subclause 6.15, "DescribeCol", General Rule 9)b): "Case:" iii): If the data type of C is datetime or interval, then ColumnSize is set to the length in positions of C." SQL/Temporal needs to define the "length in positions" of the PERIOD data type to permit SQL/CLI to be used with SQL/Temporal. TMPRL-017 WG3:BBN-166/X3H2-98-385 moved this Possible Problem from SQL/Bindings, where it was BIND-004, to here. During discussion of DBL:MCI-079/X3H2-96-112, Paul Cotton noted the following Possible Problem: DBL:MCI-079 added support for queries returning sets and multisets with any element type. This paper modified SQL/Foundation to ensure that top-level queries cannot return anything other than tables (i.e., change to to ensure that a specifies a table). Changes may be required to SQL/Bindings to ensure that cannot be applied to a or that returns anything other than a table. Note as well that the proposal in DBL:MCI-142/X3H2-96-151 (an SQL/Temporal proposal not yet adopted) uses the phrase "outermost query" to limit where a VALIDTIME query can occur (Section 15, Clause 7, Query expressions; 15.1 Subclause 7.4, SR4). These two papers appear to use an inconsistent method and wording to define where collection queries and valid-time queries can be used.

Notes–2 Editor’s Notes for (ISO-ANSI working draft) Temporal (SQL/Temporal)


Minor Problems and Wordsmithing Candidates:

Possible problems with SQL/Temporal

Notes–3


Language Opportunities



2 Guidelines for writing "user-friendly" change proposals This chapter of the Editor’s Notes offers guidelines to the style of the content of the SQL document and all its Parts, as well as some guidelines for writing change proposals. Readers should refer to the end of this Clause of the Editor’s Notes for a checklist of issues that must be addressed by change proposals. Every change proposal must clearly indicate whether or not the issue is relevant to the subject matter of the proposal and, if so, how it is addressed. The Editor reserves the right to reject any change proposals that do not follow these guidelines, as appropriate.

2.1 Style of content of SQL document 2.1.1 General 2.1.1.1

Language

Since the SQL standard will be translated into other languages, and must in any case be read and understood by many whose first language is not English, simplicity of language is much more important than literary elegance. Normal rules of good style apply; if in doubt, there are several excellent references to writing style that may be consulted. The following specific points are noted: — Conditions: The standard form used is ‘‘If some condition is satisfied, then something happens.’’ This is strongly preferred to ‘‘X happens if Y is true.’’ The ‘‘otherwise’’ case always deserves consideration, though it doesn’t always need to be stated (particularly when the otherwise case involves no action or behavior). — Number: It is clearer to stick to the singular and say, for example, ‘‘every X is destroyed’’ than to say ‘‘all xs are destroyed’’. Where ‘‘each’’ is acceptable, it is even better. — Avoid the use of the word ‘‘any’’ as far as practicable. In ordinary English, it sometimes means ‘‘some’’ (as in ‘‘have you any shares in Company X?’’), and sometimes means ‘‘every’’ (as in ‘‘you can call any day, any time’’). In particular, avoid constructions like ‘‘Let CD be any collation descriptor that includes . . . ’’. Use precise quantification, such as ‘‘For every collation descriptor CD that includes . . . ’’, and note that it is not necessary to add ‘‘if any’’—even if there is no such collation descriptor, the rule still works fine. — ‘‘which’’ versus ‘‘that’’: See X3H2-88-036 (copies available upon request). ‘‘That’’ should be used much more often than many people do.

2.1.1.2

Vocabulary

English is well known for having many synonyms (change, alter, amend), partially overlapping synonyms (describe and define, change and improve), and near-synonyms with subtle differences (edible and eatable), or even ignored distinctions (expect and anticipate). It may be assumed that any reader has a dictionary available, but where a word can be used in more than one sense, the correct interpretation should not depend on context any more than is absolutely necessary. If a word can have the same meaning or translation into another language as some other word used in SQL3 and no distinction is intended, then that other word should be used in preference.

Guidelines for writing "user-friendly" change proposals

Notes–5

Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.1 Style of content of SQL document Particular words used in specific senses in SQL3 include: — Definition: Either a BNF non-terminal that causes the creation of something, or a definition of the meaning of a term. — Descriptor: A persistent, formal description of an SQL object. See Subclause 7.2.4, "Descriptors", in Part 1. — Specify: To state explicitly, for example ‘‘If GLOBAL is specified, . . . ’’ means ‘‘If the word ’GLOBAL’ actually appears, . . . ’’. Note that ‘‘ . . . is specified . . . ’’ appears more frequently than ‘‘ . . . was specified . . . ’’. — Case: is favored. Nested cases are preferred to complex ones. Only the first rule is applied for which the condition is satisfied, so the order of the subrules is important. A Case construct normally ends with an ‘‘Otherwise’’ subrule, but this is not necessarily required. Other terms worth noting are: — Database: Note: this is one word. A collection of SQL-data. The term is to be avoided, because it raises the question of whether databases can overlap, be nested, are each described by a catalog or cluster of catalogs, etc. Usually, the term ‘‘SQL-data’’ is sufficient. — Description: An informal description; not used in a technical sense. Note that the object that serves as a persistent description of an SQL object is known as a descriptor.

2.1.1.3

Quantification

When universally quantifying, prefer the singular ‘‘every’’ to the plural ‘‘all’’—it nearly always works better. Although mathematicians often say ‘‘for all x’’, it is not really good grammar (because the upside-down A (8) of predicate calculus is considered to stand for ‘‘all’’, the first letter of ‘‘every’’ having been taken by the backwards E (9) that stands for ‘‘exists’’). When existentially quantifying, use ‘‘some’’, not only in preference to ‘‘any’’, but also sometimes in preference to the indefinite article ‘‘a’’ or ‘‘an’’, which can be as ambiguous as ‘‘any’’. However, this suggestion can lead to ‘‘overkill’’ text, so we further suggest that the indefinite article is appropriate in cases where it is clear that there can be no more than one occurrence of the thing in question, as in : ‘‘For every collation descriptor that includes a . . . ’’ (a collation descriptor includes at most one , so the word ‘‘some’’ instead of ‘‘a’’ could even be misleading here).

2.1.1.4

Quotation marks

Single s (’) enclose s; s (") enclose s. In text, double quotes (") are normally used to surround quoted material.

2.1.1.5

Typography

— s (only) are in s. — Truth values (as opposed to Boolean values) are lower-case, italicized, and underlined: true , false , and unknown .


Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.1 Style of content of SQL document — With the exception of certain index entries and certain table headings, the only bolding in the document is of: •

Ada keywords such as package, because the Ada convention is followed;

•

The terms being defined in Subclause 3.1, "Definitions"; and

•

Names of pseudo-procedures (visible now only in the definition of significant DB_changes, where the procedure proc_VC is defined).

— Clauses (‘‘chapters’’ to some) are the major divisions in the document; Subclauses are all the lesser divisions. The names of Clauses and Subclauses are all spelled with initial capital letters; subsequent words in those names are spelled with initial lower-case letters—except, of course, for such words as ‘‘SQL’’.

2.1.2 SQL terminology 2.1.2.1

Terms for SQL objects

Terms referring to SQL objects must be carefully chosen, and used not only correctly but wherever possible. Such terms are frequently prefixed with ‘‘SQL-’’ in order to distinguish them from similar terms used with different meanings in related contexts. For example: SQL-transaction, SQL-session, SQL-client. Note that SQL-schema is, strictly, the correct term, because it has a different meaning from ‘‘schema’’ in the Reference Model of Data Management, but ‘‘schema’’ is used throughout the SQL document because it is always the SQL sense that is intended. Ambiguities such as ‘‘object identifier’’ should be avoided.

2.1.2.2

BNF non-terminal symbols

The names of BNF non-terminals do not often contain hyphens; where they do, it is normally because the analogous English phrase would contain hyphens (‘‘form-of-use’’, ‘‘implementationdefined’’). They sometimes contain colons to distinguish closely related constructs (for example, and ). Care should be taken not to introduce over-general names. For example, is unfortunate in that its production rule does not allow any SQL-statement. Every new must be specified as a or , as appropriate. Precision in referring to BNF non-terminals is important. For example: there is no such thing as a . Do not fall into the trap of assuming that the name of a BNF non-terminal means the same thing as the words contained within the angle brackets. When writing a rule about , do not then start using the phrase ‘‘select list’’ as though it has some meaning. BNF non-terminals are nothing more than distinguished character strings whose spelling is irrelevant except for consistent use. If ‘‘’’ were replaced ‘‘automatically’’ with ‘‘’’, one would not feel comfortable discussing the ‘‘SL’’ as a normal English phrase.


Notes–7

Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.1 Style of content of SQL document

2.1.2.3

BNF non-terminal or name of SQL object?

BNF non-terminals do not denote persistent objects. In particular, it is incorrect to say ‘‘If an exists . . . ’’; an is source code, which, once processed, ceases to exist as far as the SQL implementation is concerned. The result of processing it is an assertion, represented by an assertion descriptor in some schema. data type or ? ‘‘data type’’ is the correct term, unless it is specifically intended to refer to the BNF nonterminal ‘‘’’ (probably appropriate only when discussing the syntax). Where reference is intended to a generic data type, such a character string type, then that is the preferred term.. SQL, at the time of writing, uses ‘‘character data type’’, ‘‘’’, ‘‘data type CHARACTER’’, and several other phrases almost synonymously. ‘‘’’ is a BNF non-terminal; ‘‘prepared statement’’ is not.

2.1.2.4

Notes on specific SQL terms

‘‘contain’’ is used for syntactic containment, i.e., one BNF non-terminal is said to contain others. ‘‘data type’’ is two words. ‘‘datetime’’ is one word. ‘‘include’’ is used for specifying that one descriptor is included in others.

2.1.2.5

Locally-defined terms and symbols

Diacritical or other marks, such as prime, are to be avoided for typographical reasons. Other considerations involving terms and symbols: — Symbolic names are italicized and composed of s and s. Examples: T, C1, and SLCC. — Indexes or subscripts are in lower-case italic letters and digits. Examples: ‘‘the i-th column’’, ‘‘Ck ’’, or ‘‘at least j values’’. — Special symbols for use as ‘‘range variables’’ (like the ‘‘CD’’ earlier) should not be introduced unnecessarily. For example: Every aardvark-reference A that contains . . . is removed from every zoological paper that includes A. is preferable to: For every zoological paper ZP, for every aardvark-reference A that contains . . . and is included in ZP, A is removed from ZP. Special symbols are necessary to avoid clumsiness and to ensure precision in many of the more complicated rules. These special symbols’ scope is the Subclause in which they are defined. While they may be defined early in a Subclause (for example, in the Syntax Rules) and used much later (for example, in the General Rules), it is preferable to define them in the section in which they are used within a Subclause.


Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.1 Style of content of SQL document

2.1.2.6

Abbreviations

Abbreviations such as ‘‘auth-id’’ are not used in the SQL standard, however widely they may be generally used and understood. It follows that they are not acceptable in text proposed for insertion in the document.

2.1.3 The content of the SQL standard 2.1.3.1

Definitions

This section should conform to the (normative!) Annex B.1 of the ISO Directives, Part 3. A term should be defined in this section if and only if: — It is used through the Standard, rather than in any particular context; and — Either: •

It is a term not widely used or that has been invented for the Standard; or

•

It has more than one meaning and a precise meaning is consistently intended in the Standard.

A term should not be included simply for tutorial purposes (the Standard is already large enough).

2.1.3.2

Concepts

Although Clause 4, "Concepts", was originally introduced purely for the purpose of explanation, it now contains much material that is definitive. There are no guidelines to what should or should not be there. Thus Subclause 4.2.3, "Rules determining collating sequence usage", are classed as concepts, while tables of valid casts and valid values of datetime data types are not.

2.1.3.3

Modularity

Except perhaps where the result would be a ridiculously short Subclause, the specification of a BNF non-terminal used in more than one place should be in a separate Subclause from every one of its uses. Otherwise, there is a serious risk of unintended effects resulting from changing the Rules in one place without realizing that they should remain unchanged for the use elsewhere. In particular, the construct ‘‘Every General Rule except General Rule 1 of Subclause x.y applies here with ’something’ replaced by ’something else’’’ is to be avoided at all costs.

2.1.3.4

Format

The syntax of the version of BNF used is defined in Subclause 3.2, "Notation". Every SQL character that is not a letter or digit has a name, defined in Subclause 5.1, "". Except in those BNF productions that define names for them, such characters never appear standing for themselves, but are always represented by their names. Thus, except where they are specified as , etc., the characters ‘‘[’’, ‘‘]’’, ‘‘{’’, ‘‘}’’, ‘‘ | ’’, and ‘‘ . . . ’’ in BNF productions always serve as "punctuation".


Notes–9

Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.1 Style of content of SQL document Therefore, the production: ::= ( [ , ]... )

should always be written as: ::= [ ]...

2.1.3.5

Syntax Rules, Access Rules, and General Rules

The differences between Syntax and Access Rules on the one hand and General Rules on the other are that Syntax and Access Rules specify requirements for a program to conform to (some level of) the SQL standard, while General Rules specify what a standard-conforming SQL implementation is required to do when it process such a standard-conforming program. Where there are no Rules of any kind, it is usual to say ‘‘None.’’, to exclude the possibility that they have not been thought about, or have been lost.

2.1.3.6

Syntax Rules

The correct form is ‘‘This condition shall be satisfied . . . ’’ or ‘‘If X is specified, then Y shall be specified’’. Syntax Rules do not deal with the privileges required to accomplish some action.

2.1.3.7

Access Rules

The correct form is as for Syntax Rules. Access Rules do deal with the privileges required to accomplish some action.

2.1.3.8

General Rules

General Rules specify the effect of processing SQL source code that satisfies the relevant Format, Syntax Rules, and Access Rules. The preferred form is present indicative passive, e.g., ‘‘A descriptor is created . . . ’’. By the time the Syntax and Access Rules have been processed, certain implications have become explicit. Thus, if the optional of a is omitted, it is deduced, and by the time General Rule 1) is encountered, it can be assumed that is known. It is not normally necessary or desirable to mention that it is ‘‘explicit or implicit’’.

2.1.3.9

Exceptions

There are two categories of end-of-statement behavior: — ‘‘ . . . an exception condition is raised: some condition’’; and


Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.1 Style of content of SQL document — ‘‘ . . . a completion condition is raised: limited alternatives’’. The only acceptable alternatives for the completion conditions are successful completion, warning, and no data. Each of these may have no subcode or a specific subcode. The exception class and subclass phrases are separated by a dash ‘‘—’’ and are always both in italics.

2.1.3.10

Leveling Rules

The correct form is as for Syntax Rules. A Rule that illustrates a point by the use of an SQL expression either shows the SQL expression on a separate line: Let B be an exact numeric result of the operation: CAST (CAST (Y AS Q) AS E2) or encloses the expression in double-quotes: ‘‘R is NULL’’ is true if and only if . . .

2.2 Writing change proposals 2.2.1 Discussion It is helpful to the reader if the discussion part makes quite clear why the proposal is being made. It also helps if any approaches that were considered and rejected are also mentioned, together with the reasons for their rejection. Proposal writers should strive to describe all changes and their implications in the discussion part. Readers should have have to slog through the detailed language changes to understand the consequences of the change.

2.2.2 Change proposals A) Every separate item of the proposal should be numbered. B) When referring to a Subclause of the document, always specify both Subclause number and the name of the Subclause (for example, Subclause 6.1, ""). C) When inserting, deleting, or replacing text or Rules in the document, specify both the reference, e.g., Syntax Rule 11)c)iv)2)B), and sufficient context to identify the specific paragraph, sentence, or Rule to be changed. For example, to replace Subclause x.y, Syntax Rule 11)c)iv)2)B), each of Syntax Rules 11), 11)c), 11)c)iv), and 11)c)iv)2) should be unambiguously defined. Where, as for example in Subclause 15.9, "", several Rules start off very similarly, say something like "Replace Syntax Rule 11)c)iv)2)B) (the Rule that deals with the xyz in an rst) with...". D) Where only a few words of existing text are to be changed, it is clearer both to the reviewer and the Editor to flag differences in some way, e.g., by striking out deleted text and underlining new text or setting new text in boldface. Whatever convention is used should be explained.


Notes–11

Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.2 Writing change proposals

2.2.3 Use of Notes Change proposals often must to draw the (proposal) reader’s attention to some detail or explanation. This is best done by means of a note starting off with ‘‘Note to proposal reader:’’. Similarly, change proposal sometimes need to call the Editor’s attention to some detail, such as the need to assign an SQLSTATE class code or subclass code to a condition. This is best done by means of a note starting off with ‘‘Note to the Editor:’’. However, there is also the need for change proposals to insert notes into the text of the document that they modify, so that the reader of the resulting standard has access to the note text. This is best done by specifying something like ‘‘NOTE nnn: text of the note’’.

2.2.4 Check list All changes to the document must be specified explicitly. It is unfair to the Editor to expect him to make changes left implicit or unspecified. The following list is provided in the hope of reducing the number of incomplete change proposals: •

Conformance Rules and Appendix A, "SQL Conformance Summary",

•

Appendix B, "Implementation-defined elements" or Appendix C, "Implementation-dependent elements",

•

Appendix E, "Incompatibilities with X3.135-1992 and X3.135.4-1996", especially for new s,

•

Appendix E, "Incompatibilities with X3.135-1992 and X3.135.4-1996", for new class or subclass values—also please remind the Editor to index the new SQLSTATE values; also update the table of Ada package values in SQL/Foundation, Subclause 13.4, "Calls to an ".

•

The Dynamic SQL Descriptor Area

•

Information and Definition Schemas.

A proposal that solves a Possible Problem, Minor Problem, or Opportunity, whether intentionally or not, should say so prominently, so that the Editor’s Notes may be kept up-to-date. A proposal that introduces a Possible Problem, for example because it is admittedly incomplete, should specify an appropriate addition to the Possible Problems list. The same applies to language opportunities. A proposal to insert lengthy pieces of text into the document should, either before or as soon as practicable after it has been adopted, be provided to the Editor in machine-readable form, either on diskette or by electronic mail (see Clause 3, ‘‘Machine readable change proposals’’ for more information). It is accepted that this machine-readable version will be in ‘‘plain text’’ form and without many formatting attributes (e.g., bolding, underlining, font changes), but it is nevertheless of great help to the Editor.


Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.2 Writing change proposals

2.2.5 The End Of The Paper Not everybody’s printers and computers work perfectly every time. It sometimes happens that an attempt to print a change proposal or other paper terminates prematurely, but it is not always obvious to the reader that the paper is not completely printed. There are ways to combat this. It is very strongly suggested that you end your change proposals (and, indeed, even discussion papers) with some notation like: = == == == == == == == == == == == == == == == == == == == == End of paper. = == == == == == == == == == == == == == == == == == == == == Alternatively, you could choose to number each page with the formula "Page n of m", where "m" is the total number of pages. This approach has the disadvantage that many word processors happily print an incorrect value for "m". If you choose this approach, you will have to be extremely careful that the value is correct. Perhaps you could combine this approach with the previous suggestion for maximum benefit.

2.2.6 Format for Possible Problems and Language Opportunities All Possible Problems and Language Opportunities should be provide, preferably in electronic, machine-readable form, to the Editor using the following format: Severity: One of Major Technical, Minor Technical, and Major Editorial. Reference: A specific document and either Clause or Subclause, identified by both number and name. •

The document number should be of the form "Pnn", where "nn" represents the part number, including leading zeros to make it a 2-digit number. For example, P02 would be used for SQL/Foundation. Terminate this with a period to separate it from the Clause or Subclause number.

•

The Clause or Subclause number should have two digits per level (including leading zeros) such as "03: or "04.21.01".

•

The name should be spelled exactly as it is currently specified in the base documents, but not enclosed in quotation marks. You should not use a comma between the number and the name.

•

The word Clause or Subclause should not be used in this item.

•

If the PP or LO doesn’t apply to a specific Clause or Subclause in the document, then use the phrase "No specific location".

Examples of properly formatted references are: •

P02.No specific location

• P05.04.06.01 Classes of SQL-statements Note at: A specific location within an identified Clause or Subclause. This would identify the paragraph, Function, Format production, Syntax Rule, Access Rule, General Rule, Leveling Rule, or Description at which the Editor should put a note referencing the Possible Problem or Language Opportunity. If the PP or LO does not apply to such a specific place, then the word "None" should be specified here.


Notes–13

Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.2 Writing change proposals Source: The name of the person or the paper number that proposed the PP or LO, as well as the date on which it was submitted. Possible Problem: or Language Opportunity: This is the actual text of the PP or LO (use only one of those two phrases, of course!), taking as many paragraphs as you need. Proposed Solution: This is the actual text of a proposed solution. If none is proposed, then "None submitted with comment" should be specified. Because of the increasing size and partitioning of the SQL3 document and the great complexity of dealing with proposals that make substantial changes to the document’s structure and content, I reserve the right to decline instructions to change the document when those instructions are not complete and that do not generally follow these guidelines. Specifically, if a change proposal is accepted that fails to cite the number and title of the document being changed by the proposal, the proper Clause and/or Subclause numbers and titles affected by the proposal, and the Rule numbers and partial text of Rules that are changed by the proposal, then I will not make any changes in the next edition of the base document, but will bring the paper back to the Committee for revision and completion. Thanks!

2.3 A Checklist of Issues to be Addressed by Change Proposals 1) Concepts — If a proposal introduces new concepts into the SQL language or substantially modifies support for existing concepts, then Clause 4, "Concepts", and/or Part 1, SQL/Framework, must be updated to reflect the new reality. 2) Access Rules — If new schema objects are introduced, then formulating their relevant Access Rules may be obvious; however, in other cases, it may be less obvious that Access Rules are required to be specified or modified. The impact on referring to new schema objects shall be addressed, as well as access control such as and . 3) Conformance Rules, including the relevant Annexes — Every new feature, however small, must be either explicitly excluded from Core SQL by means of a Conformance Rule or included in Core SQL by defining its capabilities 4) Packages, including the relevant Annexes — New features of SQL should be considered for inclusion in either an existing package of SQL or a new package; absent such inclusion, proposals should explicitly state that the feature is not to be included in any package. 5) Lists of SQL-statements by category — Adding new SQL statements to the language requires that they be considered for membership in one or more of several categories of statements found in the Concepts. 6) Table of identifiers used by diagnostics statements — Every new SQL statement must have a character string identifier and a numeric identifier assigned for use by diagnostics statements and by dynamic SQL statements. 7) Collation coercibility determination for changes related to character strings — Any time new character string-related facilities are added to the language (including, for example, a new type of expression), the collation coercibility characteristic must be addressed.


Editor’s Notes for DBL:YGJ-016 and X3H2-99-084 2.3 A Checklist of Issues to be Addressed by Change Proposals 8) Closing Possible Problems when a proposal resolves them — Many proposal resolve previouslydiscovered problems in the SQL language or fulfil a previously-stated desire for a new feature. Proposals must state whether their acceptance can result in closing existing Possible Problems or Language Opportunities. 9) Any new Possible Problems clearly identified — If a proposal identifies, but does not solve, a previously-unidentified (or unrecorded) problem, it must clearly instruct the Editor to enter a new Possible Problem. 10) Reserved and non-reserved keywords — Many, if not most, new SQL facilities depend on keywords and often introduce new keywords. Every new use of an existing keyword must consider whether it causes a previously un-reserved word to have to become reserved; every introduction of a new keyword must insert it into either the list of s or the list of s. 11) SQLSTATE tables and Ada package — Whenever any new exception condition or completion condition is used in the documents, it must be accompanied by a specification to include it in the SQLSTATE value tables (considering whether a new class code is required or whether it can be done by means of a new subclass code within an existing class code); simultaneously, the Ada package specifying Ada identifiers for SQLSTATE values must be updated to include the new condition. 12) Information and Definition Schemas — Every new schema object must be reflected in the Information and Definition Schemas. This must include the "short names" tables and views in those Schemas, too! 13) Implementation-defined and -dependent Annexes — Every new specification of some aspect of SQL as implementation-defined or implementation-dependent must be accompanied by a corresponding entry in the appropriate Annexes. 14) Incompatibilities Annex — Whenever an incompatibility with a previous version of the language is introduced, it must be documented in the appropriate Annex. 15) Embedded SQL bindings and host language implications — If a proposal affects host language bindings in any way (including, but not limited to, addition of new data types or mappings of existing data types), the embedded SQL facilities must be examined for impacts. 16) Dynamic SQL issues: including Dynamic descriptor areas — Many changes to host language bindings, introduction of new SQL statements or new data types, and other categories of changes have implications on Dynamic SQL; proposals must address this area of the language explicitly. 17) CLI issues — Most proposals that have Dynamic SQL implications also cause changes to be required in CLI; such proposals must explicitly make the required changes to SQL/CLI in order to be considered complete. This requires inclusion of a second checklist, indicated below.


Notes–15




3 Machine readable change proposals I would like to thank those ISO and ANSI participants who have provided change proposals in machine-readable form. This practice reduces the editorial workload considerably and makes it much easier to ensure accurate reflection of the change proposals in the base document. I continue to urge those participants who can supply machine-readable versions of lengthier proposals (i.e., a page or more of new text) to post those proposals directly to the SQL Standards Archives or, failing that, to bring those diskettes to meetings, in order to avoid mail delays. I will of course either return the diskettes or replace them with blank diskettes on request. The best mechanism, as we’ve seen recently, is to post proposals in several forms (PDF, PS, and plain text are all desirable) into the SQL Standards Archives (currently located at jerry.ece.umassd.edu). If you cannot post your proposals, then you are encouraged to provide them to the Editor on diskette. I prefer 3.5 inch DS/HD soft-sectored diskettes, with DOS files (clearly labeled in any case!). I may be able to find ways to copy other types of diskette and file, but would prefer to avoid the hassles if possible. Please include both unformatted and formatted versions of each file, if possible. Fully-justified text (with the extra blanks inserted for alignment purposes) do not appear to be a problem for my document processor. It may be preferable for you to electronically mail me your change proposals. My Internet mail address is: [email protected] Thanks!

Machine readable change proposals

Notes–17

Index Index entries appearing in boldface indicate the page where the word, phrase, or BNF nonterminal was defined; index entries appearing in italics indicate a page where the BNF nonterminal was used in a Format; and index entries appearing in roman type indicate a page where the word, phrase, or BNF nonterminal was used in a heading, Function, Syntax Rule, Access Rule, General Rule, Leveling Rule, Table, or other descriptive text.

999 • 1

—B— BIND-004 • 2

—T— TMPRL-013 TMPRL-014 TMPRL-015 TMPRL-017

•1 •1 • 1, 2 •2

Index 1

ISO Working Draft Database Language SQL — Part 7: Temporal (SQL/Temporal) «Part 7»

March 1999

Contents

Page

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 1

Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2

Normative references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Definitions, notations, and conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Relationships to other parts of ISO/IEC 9075 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1.1 New and modified Clauses, Subclauses, and Annexes . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1.2 New and modified Format items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1.3 New and modified paragraphs and rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1.4 New and modified tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1.5 Clause, Subclause, and Table relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Object identifier for Database Language SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 5 5 5 6 6 6 7 7 8 11

4 Concepts . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Introduction to SQL/Temporal . . . . . . 4.2 Period data type . . . . . . . . . . . . . . . . . 4.2.1 Operations involving periods . . . . . . . 4.2.2 Period type conversions and mixing of 4.2.3 Period predicates . . . . . . . . . . . . . . . .

13 13 13 13 14 14

.... .... .... .... data ....

..... ..... ..... ..... types .....

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5 Lexical elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1 and . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6 Scalar expressions . . . . . . . . . . . . . 6.1 . . . . . . . . . . . . . . . . . . 6.2 . . . . . . 6.3 . . . . . . . . . . . . 6.4 . . . . . . . . . . . . . 6.5 . . . . . . . 6.6 .

ii

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

(ISO-ANSI working draft) Temporal (SQL/Temporal)

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

19 19 20 21 23 25 27

WG3:YGJ-016 = X3H2-99-084

6.7 6.8

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 Query expressions . . . . . . . . . . . 7.1 7.2 . . . . . . . . . . 7.3 . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

31 31 33 34

8 Predicates . . . . . . . . . . . 8.1 . . . . . . . . . 8.2 8.3 . . 8.4 . . . . 9 9.1 9.2 9.3

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

37 37 38 39 41

Data assignment rules . . . . . . . Retrieval assignment . . . . . . . . Store assignment . . . . . . . . . . . Set operation result data types

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

43 43 44 45

10 Schema definition and manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 10.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 11 Dynamic SQL . . . . . . . . . . . . . . . . . . . . . . . 11.1 Description of SQL item descriptor areas . 11.2 . . . . . . . . . . . . 11.3 . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

49 49 51 52

12 Definition Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 12.1 DATA_TYPE_DESCRIPTOR base table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 13 Status codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 13.1 SQLSTATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 14

Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Annex A

Implementation-defined elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Annex B

Implementation-dependent elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Annex C

Deprecated features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Annex D

Incompatibilities with X3.135-1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Annex E

SQL Feature Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index1

Contents iii

WG3:YGJ-016 = X3H2-99-084

TABLES Tables 1 2 3 4

iv

Page Clause, Subclause, and Table relationships . . . . . . . . . . . . . . . . . . . . . . Codes used for SQL data types in Dynamic SQL . . . . . . . . . . . . . . . . . . Codes associated with datetime and period data types in Dynamic SQL SQLSTATE class and subclass values . . . . . . . . . . . . . . . . . . . . . . . . . .


. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

8 49 50 55

WG3:YGJ-016 = X3H2-99-084

Foreword

ISO Only—caused by ANSI changes not yet considered by ISO

ISO (the International Organization for Standardization) and IEC (the International 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 committees collaborate in fields of mutual interest. Other international organizations, 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, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75% of the national bodies casting a vote. International Standard ISO/IEC 9075, Part 7, was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology. ISO/IEC 9075 consists of the following parts, under the general title Information technology — Database languages — SQL: — Part 1: Framework (SQL/Framework) — Part 2: Foundation (SQL/Foundation) — Part 3: Call-Level Interface (SQL/CLI) — Part 4: Persistent Stored Modules (SQL/PSM) — Part 5: Host Language Bindings (SQL/Bindings) — Part 6: XA Specialization (SQL/Transaction) — Part 7: Temporal (SQL/Temporal) — Part 8: Extended Objects (SQL/Object) — Part 9: Virtual Tables (SQL/VirtualTable)

ANSI Only—caused by ISO changes not yet considered by ANSI To be supplied if required.

Foreword v

WG3:YGJ-016 = X3H2-99-084

Annexes A, B, C, and D of this Part of the Information Standard are for information only.

vi


WG3:YGJ-016 = X3H2-99-084

Introduction

The organization of this Part of this International Standard is as follows: 1) Clause 1, ‘‘Scope’’, specifies the scope of this part of this International Standard. 2) Clause 2, ‘‘Normative references’’, identifies additional standards that, through reference in this part of this International Standard, constitute provisions of this part of this International Standard. 3) Clause 3, ‘‘Definitions, notations, and conventions’’, defines the notations and conventions used in this part of this International Standard. 4) Clause 4, ‘‘Concepts’’, presents concepts related to this Parts of this International standard related to the support of time. 5) Clause 5, ‘‘Lexical elements’’, defines a number of lexical elements used in the definition of temporal support. 6) Clause 6, ‘‘Scalar expressions’’, defines a number of scalar expressions used in the definition of temporal support. 7) Clause 7, ‘‘Query expressions’’, defines the elements of the language that produce rows and tables of data, enhances for temporal support. 8) Clause 8, ‘‘Predicates’’, defines a number of predicates used in the manipulation of temporal support. 9) Clause 9, ‘‘Data assignment rules’’, specifies the rules for assignments that retrieve data from or store data into SQL-data, and formation fules for set operations. 10) Clause 10, ‘‘Schema definition and manipulation’’, defines facilities for creating and managing a schema. 11) Clause 11, ‘‘Dynamic SQL’’, defines temporal support in the SQL dynamic statements. 12) Clause 12, ‘‘Definition Schema’’, defines base tables on which the viewed tables containing schema information depend. 13) Clause 13, ‘‘Status codes’’, defines SQLSTATE values related to temporal support. 14) Clause 14, ‘‘Conformance’’, defines the criteria for conformance to this Part of this International Standard. 15) Annex A, ‘‘Implementation-defined elements’’, is an informative Annex. It lists those features for which this part of ANSI ANSI X3.135 ISO ISO/IEC 9075 states that the syntax, the meaning, the returned results, the effect on SQL-data and/or schemas, or any other behavior is partly or wholly implementation-defined.

Introduction

vii

WG3:YGJ-016 = X3H2-99-084

16) Annex B, ‘‘Implementation-dependent elements’’, is an informative Annex. It lists those features for which the body of this part of ANSI ANSI X3.135 ISO ISO/IEC 9075 states that the syntax, the meaning, the returned results, the effect on SQL-data and/or schemas, or any other behavior is partly or wholly implementation-dependent. 17) Annex C, ‘‘Deprecated features’’, is an informative Annex. It lists features that the responsible Techical Committee intends will not appear in a future revised version of this International Standard. 18) Annex D, ‘‘Incompatibilities with X3.135-1992’’, is an informative Annex. It lists the incompatibilities between this version of this International Standard and ISO/IEC 9075:1992. In the text of this International Standard, Clauses begin a new odd-numbered page. Any resulting blank space is not significant.

viii


Information technology — Database languages — SQL — Part 7: Temporal (SQL/Temporal) 1 Scope This Part of International Standard ISO/IEC 9075 defines the facilities by which a conforming SQLimplementation can support temporal data. The database language for temporal support includes: — the specification of a data type constructor named PERIOD; and — the specification of scalar expressions and predicates used to manipulate values of period data types. NOTE 1 – The framework for this International Standard is described by the Reference Model of Data Management (ISO/IEC 10032:1993).

Scope

1

WG3:YGJ-016 = X3H2-99-084

2 (ISO-ANSI working draft) Temporal (SQL/Temporal)

WG3:YGJ-016 = X3H2-99-084

2 Normative references The following standards contain provisions that, through reference in this text, constitute provisions of this Part of this National Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards.

ANSI Only—caused by ISO changes not yet considered by ANSI

ANSI X3.9-1978, American National Standard Programming Language FORTRAN. ANSI X3.23-1985, American National Standard for Information Systems—Programming Language—COBOL. ANSI X3.53-1976, American National Standard Programming Language PL/I. ANSI X3.135-1992, American National Standard for Information Systems — Database Language — SQL. ANSI X3.159-1989, American National Standard for Information Systems—Programming Language—C. ANSI X3.198-1991, American National Standard for Information Systems—Programming Language—Fortran. NOTE 2 – ANSI X3.198-1991 introduces no incompatibilities with ANSI X3.9-1978 that affect the binding between Fortran and SQL; therefore, wherever ‘‘Fortran’’ is specified in this International Standard, ANSI X3.198-1991 is implicit.

ANSI/MDC X11.1-1990, American National Standard for Information Systems—Programming Language—MUMPS. ANSI/IEEE 770/X3.97-1983, American National Standard for Information Systems— Programming Language—Pascal. ANSI/IEEE 770/X3.160-1989, American National Standard for Information Systems— Programming Language—Extended Pascal. ANSI/MIL-STD-1815A-1983, American National Standard for Information Systems—Reference Manual for the Ada® Programming Language.


Normative references

3

WG3:YGJ-016 = X3H2-99-084

ISO/IEC 1539:1991, Information technology — Programming languages — Fortran. ISO 1989:1985, Programming languages — COBOL. ISO 6160:1979, Programming languages — PL/I. ISO\IEC 7185:1990, Information technology — Programming languages — Pascal. ISO 8652:1987, Programming languages — Ada. ISO/IEC 9075-1:1999, Information Technology — Database Languages — Part 1: Framework (SQL/Framework). ISO/IEC 9075-2:1999, Information Technology — Database Languages — Part 2: Foundation (SQL/Foundation). ISO/IEC 9075-3:1999, Information Technology — Database Languages — Part 3: Call-Level Interface (SQL/CLI). ISO/IEC 9075-4:1999, Information Technology — Database Languages — Part 4: Persistent stored modules (SQL/PSM). ISO/IEC 9075-5:1999, Information Technology — Database Languages — Part 5: Host language bindings (SQL/Bindings). ISO/IEC 9075-6:199x, Information Technology — Database Languages — Part 6: XA specialization (SQL/Transaction). ISO/IEC 9899:1990, Information technology — Programming languages — C. ISO/IEC 10206:1991, Information technology — Programming languages — Extended Pascal. ISO/IEC 11756:1992, Information technology—Programming languages—MUMPS.


WG3:YGJ-016 = X3H2-99-084

3 Definitions, notations, and conventions 3.1 Definitions For the purposes of this International Standard, the following definitions apply. All definitions in Parts 1 and 2 of this International Standard apply to this Part or this International Standard. This Part of this International Standard defines the following terms: a) beginning bound (of a period): the least value in a period. b) element type: the data type of the elements of a value of a collection data type or a period data type. c) ending bound (of a period): the least value of the element type that is greater than the last element of a period. d) granule: a period of the minimum duration representable at a given precision; i.e., containing a single element. For PERIOD (TIMESTAMP (P)), the duration of a granule is 100P seconds. A granule may be denoted by a single value of a data type, or by a period whose last element is equal to its beginning bound. e) last element (of a period): The element that is greater than every other element. f) period: a convex set of values P of some well ordered (datetime) data type (known as the element type). That is to say: if two values, V1 and V2 are in P, and there is a value V3 such that V1 V3 V2, then V3 is in P.

3.2 Notations All notations in Part 1 and Part 2 of this International Standard apply to this Part. The syntax notation used in this Part of this International Standard is an extended version of BNF (‘‘Backus Normal Form’’ or ‘‘Backus Naur Form’’). This version of BNF is fully described in Part 2 of this International Standard.

3.3 Conventions Except as otherwise specified in this Part of this International Standard, the conventions used in this Part of this International Standard, are identical to those described in Subclause 3.3, "Conventions", of Parts 1 and 2 of this International Standard. The contents of this Part of this International Standard depend wholly on Part 2 and Part 5 of this International Standard. For example, the Syntax found in the Format portions of this Part of this International Standard often uses symbols that are defined in Part 2 or Part 5 of this International Standard.

Definitions, notations, and conventions

5

WG3:YGJ-016 = X3H2-99-084 3.3 Conventions

3.3.1 Relationships to other parts of ISO/IEC 9075 This part of ISO/IEC 9075 depends on part 2 of ISO/IEC 9075 and its Technical Corrigenda. This part of ISO/IEC 9075 is to be used as though it were merged with the text of part 2 of ISO/IEC 9075. This Subclause describes the conventions used to specify the merger. The merger described also accounts for the Technical Corrigenda that have been published to correct part 2 of ISO/IEC 9075. This accommodation is typically indicated by the presence of a phrase like ‘‘in the Technical Corrigenda’’ or ‘‘in the TC’’.

3.3.1.1

New and modified Clauses, Subclauses, and Annexes

Clauses, Subclauses, and Annexes (other than Clause 1, ‘‘Scope’’, and Clause 2, ‘‘Normative references’’) in this part of ISO/IEC 9075 that have names identical to Clauses, Subclauses, or Annexes in part 2 of ISO/IEC 9075 supplement the Clause, Subclause, or Annex, respectively, in part 2 of ISO/IEC 9075, typically by replacing paragraphs, Format items, or Rules or by providing new paragraphs, Format items, or Rules. However, Clauses, Subclauses, and Annexes in this part of ISO/IEC 9075 that have names identical to Clauses, Subclauses, and Annexes in part 2 of ISO/IEC 9075 do not necessarily have the same number or letter as the corresponding Clause, Subclause, or Annex in part 2 of ISO/IEC 9075. Any differences in Clause or Subclause number or in Annex letter is not significant. Table 1, ‘‘Clause, Subclause, and Table relationships’’, identifies the relationships between Clauses, Subclauses, and Annexes in this part of ISO/IEC 9075 and the corresponding Clauses, Subclauses, and Annexes in other parts of ISO/IEC 9075. Clauses, Subclauses, and Annexes in this part of ISO/IEC 9075 that have names that are not identical to Clauses, Subclauses, or Annexes in part 2 of ISO/IEC 9075 provide language specification particular to this part of ISO/IEC 9075. Subclauses that are subsidiary to (‘‘contained in’’) Clauses or Subclauses identified as new are inherently new and are not further identified. The Clauses, Subclauses, and Annexes in this part of ISO/IEC 9075 appear in the order in which they are intended to appear in the merged document. Absent other explicit instructions regarding its placement, any new Clause, Subclause, or Annex is to be positioned as follows: Locate the prior Clause, Subclause, or Annex in this part of ISO/IEC 9075 whose name is identical to the name of a corresponding Clause, Subclause, or Annex that appears in another part of ISO/IEC 9075. The new Clause, Subclause, or Annex shall immediately follow that Clause, Subclause, or Annex. If there are multiple new Clauses, Subclauses, or Annexes with no intervening Clause, Subclause, or Annex that modifies an existing Clause, Subclause, or Annex, then those new Clauses, Subclauses, or Annexes appear in order, following the prior Clause, Subclause, or Annex whose name was matched.

3.3.1.2

New and modified Format items

In modified Subclauses, Format items that define a BNF nonterminal symbol (that is, the BNF nonterminal symbol appears on the left-hand side of the ::= mark) sometimes modify a Format item whose definition appears in part 2 of ISO/IEC 9075, sometimes replace a Format item whose definition appears in part 2 of ISO/IEC 9075, and sometimes define a new Format item that does not have a definition at all in part 2 of ISO/IEC 9075. Those Format items in this part of ISO/IEC 9075 that modify a Format item whose definition appears in part 2 of ISO/IEC 9075, are identified by the existence of a ‘‘Format comment’’ such as: ::= !! All alternatives from part 2 of ISO/IEC 9075 |


WG3:YGJ-016 = X3H2-99-084 3.3 Conventions By contrast, Format items that completely replace Format items in part 2 of ISO/IEC 9075 have BNF nonterminal symbols identical to BNF nonterminal symbols of Format items in part 2 of ISO/IEC 9075, but do not state that they include any alternatives from part 2 of ISO/IEC 9075. New Format items that have no correspondence to any Format item in part 2 of ISO/IEC 9075 are not specially identified in this part of ISO/IEC 9075. In new Subclauses, all Format items are also new and require no specific marking.

3.3.1.3

New and modified paragraphs and rules

In modified Subclauses, each paragraph or Rule is marked to indicate whether it is a modification of a paragraph or Rule in part 2 of ISO/IEC 9075, or is a new paragraph or Rule in this part of ISO/IEC 9075. Modifications of paragraphs or Rules in part 2 of ISO/IEC 9075, are identified by the inclusion of an indication such as Replace the 5th paragraph , meaning that the fifth paragraph of the corresponding Subclause in part 2 of ISO/IEC 9075, is to be replaced by the paragraph to which the indication is attached, or Replace SR6)b)ii) , meaning that Syntax Rule 6)b)ii) of the corresponding Subclause in part 2 of ISO/IEC 9075, is to be replaced by the rule to which the indication is attached. In some cases, an indication such as Augments SR3) is used. When this appears, it means that the referenced Rule is extended or enhanced by the Rule to which the indication is attached. In most instances, the augmentation is the addition of a new alternative meant to support new syntax. New paragraphs or Rules in this part of ISO/IEC 9075 are indicated by the inclusion of an indication such as Insert before 2nd paragraph , meaning that the paragraph to which the indication is attached is to be read as though it were inserted preceding the second paragraph of the corresponding Subclause in part 2 of ISO/IEC 9075. Insert before GR4) should be interpreted to mean that the rule to which the indication is attached is to be read as though it were inserted preceding General Rule 4) of the corresponding Subclause in part 2 of ISO/IEC 9075. When an indication does not indicate a specific insertion point, such as Insert this paragraph or Insert this GR , then it may be read as implicitly specifying that the new text is to be appended at the end of the appropriate section (the General Rules, for example) of the corresponding Subclause in part 2 of ISO/IEC 9075. In such instructions, ‘‘SR’’ is used to mean ‘‘Syntax Rule’’, ‘‘AR’’ is used to mean ‘‘Access Rule’’, and ‘‘GR’’ is used to mean ‘‘General Rule’’. ‘‘Desc.’’ is used to mean ‘‘Description’’ and ‘‘Func.’’ is used to mean ‘‘Function’’. All paragraphs, Format items, and Rules in new Clauses or Subclauses are also new and therefore do not require further identification.

3.3.1.4

New and modified tables

Similarly, tables in this part of ISO/IEC 9075 that have names that are identical to tables in part 2 of ISO/IEC 9075 supplement the table in part 2 of ISO/IEC 9075, typically by adding or replacing one or more table entries. Tables in this part of ISO/IEC 9075 that have names that are not identical to the names of tables in part 2 of ISO/IEC 9075 are new tables specified by this part of ISO/IEC 9075. Table 1, ‘‘Clause, Subclause, and Table relationships’’, identifies the relationships between tables in this part of ISO/IEC 9075 and the corresponding tables in other parts of ISO/IEC 9075.


7

WG3:YGJ-016 = X3H2-99-084 3.3 Conventions The rows in modified tables are generally new rows to be effectively inserted into the corresponding table in part 2 of ISO/IEC 9075, though in rare cases rows already in tables in part 2 of ISO/IEC 9075 are effectively replaced by rows in the table in this part of ISO/IEC 9075. It is always obvious when such an effective replacement is required, based on equality of values in the first column of the table.

3.3.1.5

Clause, Subclause, and Table relationships

Table 1—Clause, Subclause, and Table relationships Clause, Subclause, or Table in this part of ISO/IEC 9075

Corresponding Clause, Subclause, or Table from another part

Part containing correspondence

Clause 1, ‘‘Scope’’

Clause 1, "Scope"

ISO/IEC 9075-2

Clause 2, ‘‘Normative references’’

Clause 2, "Normative references"

ISO/IEC 9075-2

Clause 3, ‘‘Definitions, notations, and conventions’’

Clause 3, "Definitions, notations, and conventions"

ISO/IEC 9075-2

Subclause 3.1, ‘‘Definitions’’

Subclause 3.1, "Definitions"

ISO/IEC 9075-2

Subclause 3.2, ‘‘Notations’’

Subclause 3.2, "Notation"

ISO/IEC 9075-2

Subclause 3.3, ‘‘Conventions’’

Subclause 3.3, "Conventions"

ISO/IEC 9075-2

Subclause 3.3.1, ‘‘Relationships to other parts of ISO/IEC 9075’’

(none)

(none)

Subclause 3.3.1.1, ‘‘New and modified Clauses, Subclauses, and Annexes’’

(none)

(none)

Subclause 3.3.1.2, ‘‘New and modified Format items’’

(none)

(none)

Subclause 3.3.1.3, ‘‘New and modified paragraphs and rules’’

(none)

(none)

Subclause 3.3.1.4, ‘‘New and modified tables’’

(none)

(none)

Subclause 3.3.1.5, ‘‘Clause, Subclause, and Table relationships’’

(none)

(none)

Subclause 3.4, ‘‘Object identifier for Database Language SQL’’

Subclause 7.3, "Object identifier for Database Language SQL"

ISO/IEC 9075-1

Clause 4, ‘‘Concepts’’

Clause 4, "Concepts"

ISO/IEC 9075-2

Subclause 4.1, ‘‘Introduction to SQL/Temporal’’

none

none

Subclause 4.2, ‘‘Period data type’’

none

none

Subclause 4.2.1, ‘‘Operations involving periods’’

none

none

Subclause 4.2.2, ‘‘Period type conversions and mixing of data types’’

Subclause 4.12, "Type conversions and mixing of data types"

ISO/IEC 9075-2


WG3:YGJ-016 = X3H2-99-084 3.3 Conventions Table 1—Clause, Subclause, and Table relationships (Cont.) Clause, Subclause, or Table in this part of ISO/IEC 9075



Subclause 4.2.3, ‘‘Period predicates’’

none

none

Clause 5, ‘‘Lexical elements’’

Clause 5, "Lexical elements"

ISO/IEC 9075-2

Subclause 5.1, ‘‘ and ’’

Subclause 5.2, " and "

ISO/IEC 9075-2

Subclause 5.2, ‘‘’’

Subclause 5.3, ""

ISO/IEC 9075-2

Clause 6, ‘‘Scalar expressions’’

Clause 6, "Scalar expressions"

ISO/IEC 9075-2


Subclause 6.1, ""

ISO/IEC 9075-2


Subclause 6.16, ""

ISO/IEC 9075-2


Subclause 6.22, ""

ISO/IEC 9075-2


Subclause 6.23, ""

ISO/IEC 9075-2


none

none


(setormultisetexp\ FULL) ISO/IEC 9075-2


none

none


none

none

Clause 7, ‘‘Query expressions’’

Clause 7, "Query expressions"

ISO/IEC 9075-2


none

none


Subclause 7.12, ""

ISO/IEC 9075-2


none

none

Clause 8, ‘‘Predicates’’

Clause 8, "Predicates"

ISO/IEC 9075-2


Subclause 8.1, ""

ISO/IEC 9075-2


Subclause 8.2, ""

ISO/IEC 9075-2


Subclause 8.12, ""

ISO/IEC 9075-2


none

none

Clause 9, ‘‘Data assignment rules’’

Clause 9, "Data assignment rules and routine determination"

ISO/IEC 9075-2


9

WG3:YGJ-016 = X3H2-99-084 3.3 Conventions Table 1—Clause, Subclause, and Table relationships (Cont.) Clause, Subclause, or Table in this part of ISO/IEC 9075


Subclause 9.1, ‘‘Retrieval assignment’’

Subclause 9.1, "Retrieval assignment"

ISO/IEC 9075-2

Subclause 9.2, ‘‘Store assignment’’

Subclause 9.2, "Store assignment"

ISO/IEC 9075-2

Subclause 9.3, ‘‘Set operation result data types’’

Subclause 9.3, "Data types of results of aggregations"

ISO/IEC 9075-2

Clause 10, ‘‘Schema definition and manipulation’’

Clause 11, "Schema definition and manipulation"

ISO/IEC 9075-2


Subclause 11.5, ""

ISO/IEC 9075-2

Clause 11, ‘‘Dynamic SQL’’

Clause 15, "Dynamic SQL"

ISO/IEC 9075-5

Subclause 11.1, ‘‘Description of SQL item descriptor areas’’

Subclause 15.1, "Description of SQL descriptor areas"

ISO/IEC 9075-5


Subclause 15.5, ""

ISO/IEC 9075-5


Subclause 15.8, ""

ISO/IEC 9075-5

Clause 12, ‘‘Definition Schema’’

Clause 21, "Definition Schema"

ISO/IEC 9075-2

Subclause 12.1, ‘‘DATA_TYPE_ DESCRIPTOR base table’’

Subclause 21.15, "DATA_TYPE_ DESCRIPTOR base table"

ISO/IEC 9075-2

Clause 13, ‘‘Status codes’’

Clause 22, "Status codes"

ISO/IEC 9075-2

Subclause 13.1, ‘‘SQLSTATE’’

Subclause 22.1, "SQLSTATE"

ISO/IEC 9075-2

Clause 14, ‘‘Conformance’’

Clause 23, "Conformance"

ISO/IEC 9075-2

Annex A, ‘‘Implementation-defined elements’’

Appendix B, "Implementationdefined elements"

ISO/IEC 9075-2

Annex B, ‘‘Implementationdependent elements’’

Appendix C, "Implementationdependent elements"

ISO/IEC 9075-2

Annex C, ‘‘Deprecated features’’

Appendix D, "Deprecated features"

ISO/IEC 9075-2

Annex D, ‘‘Incompatibilities with X3.135-1992’’

Appendix E, "Incompatibilities with X3.135-1992 and X3.135.4-1996"

ISO/IEC 9075-2

Table 2, ‘‘Codes used for SQL data types in Dynamic SQL’’

Table 4, "Codes used for SQL data types in Dynamic SQL"

ISO/IEC 9075-5

Table 3, ‘‘Codes associated with datetime and period data types in Dynamic SQL’’

Table 5, "Codes associated with datetime data types in Dynamic SQL"

ISO/IEC 9075-5

Table 4, ‘‘SQLSTATE class and subclass values’’

Table 27, "SQLSTATE class and subclass values"

ISO/IEC 9075-2



WG3:YGJ-016 = X3H2-99-084 3.4 Object identifier for Database Language SQL

3.4 Object identifier for Database Language SQL NOTE 3 – It is possible that the object identifier for SQL may have to be adjusted to account for the new structure of SQL3.


11

WG3:YGJ-016 = X3H2-99-084


WG3:YGJ-016 = X3H2-99-084

4 Concepts 4.1 Introduction to SQL/Temporal To Be Supplied.

4.2 Period data type A period data type is described by a period data type descriptor. A period data type has an element type that may be any datetime data type. The period data type descriptor for period data type PT includes: — An indication of the element type of PT. A value of that data type obtained by subtracting two values of the element type of a period may be added to or subtracted from a period, the result being a period of the same type. No other arithmetic operations on periods are permitted. A period is a representation of a set of contiguous granules of a specified precision.

For a period with data type PERIOD(TIMESTAMP(P)), a granule is one particular 100P second. For example, PERIOD(0) is a set of contiguous seconds, with each granule being a particular second. The first and last granules of a period, termed the beginning and ending delimiting timestamps, respectively, of the period, are TIMESTAMPs of the same precision as the period. The delimiting timestamps can be extracted using BEGIN and END. If WITH TIME ZONE is specified for the period, then the TIMESTAMPs returned by BEGIN and END include the timezone field. The functions BEGIN, END, and LAST return respectively the value of the beginning bound, the value of the ending bound, and the value that denotes the last granule of the period. Thus, if the data type of P1 is PERIOD(TIMESTAMP(0)), then LAST(P1) is the value of TIMESTAMP that denotes the beginning of the last second of P1, while END(P1) is one second later. END(P1) is actually the same as BEGIN(P2), where P2 is some period that is said to meet P1; that is, it follows it without overlapping, and without any intervening gap.

4.2.1 Operations involving periods Normalization is an operation that maps a set of periods to exactly one set of periods that is equivalent, in the sense that every granule that is a member of some element of the operand is a member of exactly one element in the result, and minimal, in the sense that no two elements P1 and P2 of the result are such that P1 meets P2. (The term ‘‘meet’’ is defined in Subclause 4.2.3, ‘‘Period predicates’’.) The NORMALIZE function defined in this International Standard takes as its argument a set or multiset of periods; the result is the normalized set of periods. Because the NORMALIZE function operates only on sets (or multisets) rather than tables, a is also defined, in

, so that tables with columns of data type PERIOD can be normalized with respect to one or more such columns. Let T be a table containing a period-valued column P. If, disregarding the values in P, the rows R1 and R2 in T are duplicates, then R1 and R2 are said to be value-equivalent rows with respect to P. When T is normalized on P, the result R is a table in which: Concepts

13

WG3:YGJ-016 = X3H2-99-084 4.2 Period data type — R and T have the same row type. — With respect to P, every row in T is value-equivalent to some row in R, and every row in R is value-equivalent to some row in T. — No two distinct but value-equivalent rows in R have P values that overlap or meet each other. (The terms ‘‘overlap’’ and ‘‘meet’’ are defined in Subclause 4.2.3, ‘‘Period predicates’’.)

4.2.2 Period type conversions and mixing of data types Values of type period are mutually assignable if and only if their respective element types are mutually assignable, and are mutually comparable if and only if their respective element types are mutually comparable. Two periods are ordered on their beginning bounds, or, if those are equal, their ending bounds.

4.2.3 Period predicates Period P1 precedes period P2 if LAST (P1) is less than BEGIN(P2). Period P1 contains period P2 if the BEGIN(P1) is less than or equal to BEGIN(P2) and LAST(P1) is greater than or equal to LAST(P2). Period P1 meets period P2 if END(P1) is equal to BEGIN(P2), or END(P2) is equal to BEGIN(P1). Period P1 overlaps period P2 if BEGIN(P1) is less than or equal to LAST(P2) and BEGIN(P2) is less than or equal to BEGIN(P1), or vice versa. NOTE 4 – ‘‘overlaps’’ is defined in ISO/IEC 9075-2, and this definition is compatible.


WG3:YGJ-016 = X3H2-99-084

5 Lexical elements 5.1

and

Function Specify lexical units (tokens and separators) that participate in SQL language.

Format ::= !! All alternatives from Part 2 of this International Standard | ::=

ANSI Only---caused by ISO changes not yet considered by ANSI !! All alternatives from ANSI X3.135.2 | !! All alternatives from ANSI X3.135.5 ISO Only---caused by ANSI changes not yet considered by ISO !! All alternatives from ISO/IEC 9075-2 | !! All alternatives from ISO/IEC 9075-5

::=

ANSI Only---caused by ISO changes not yet considered by ANSI !! All alternatives from ANSI X3.135.2 | !! All alternatives from ANSI X3.135.5 ISO Only---caused by ANSI changes not yet considered by ISO !! All alternatives from ISO/IEC 9075-2 | !! All alternatives from ISO/IEC 9075-5

| CONTAINS | EXPAND | EXPANDING | MEETS | NORMALIZE | PERIOD | PRECEDES | SUCCEEDS

Lexical elements

15

WG3:YGJ-016 = X3H2-99-084 5.1 and

Syntax Rules No additional Syntax Rules.

Access Rules No additional Access Rules.

General Rules No additional General Rules.


WG3:YGJ-016 = X3H2-99-084 5.2

5.2 Function Specify a non-null value.

Format ::= !! All alternatives from Part 2 of this International Standard | ::= PERIOD ::= [ ] ::= | ::= | ::= | [ ] [ ] ::= | |

Syntax Rules 1)

2)

Insert this SR Let BPD be , let BV be , let EV be , and let EPD be . If is specified, then let TZI be ; otherwise, let TZI be the empty string. Insert this SR

Case:

a) If BV contains both and , then EV shall also contain both and . Let PET be TIMESTAMP. b) If BV contains , then EV shall contain and shall not contain . Let PET be DATE.

Lexical elements

17

WG3:YGJ-016 = X3H2-99-084 5.2 c) Otherwise, BV shall contain and EV shall contain and shall not contain . Let PET be TIME. 3)

Insert this SR

The is equivalent to:

PERIOD BPD PET ’BV TZI’ , PET ’ET TZI’ EPD

Access Rules: No additional Access Rules.



WG3:YGJ-016 = X3H2-99-084

6 Scalar expressions 6.1 Function Specify a data type.

Format ::= !! All alternatives from Part 2 of this International Standard | ::= PERIOD

Syntax Rules 1)

Insert this SR If PERIOD is specified, then the immediately contained in shall be a datetime data type or shall be exact numeric with a scale of 0 (zero).



Scalar expressions

19

WG3:YGJ-016 = X3H2-99-084 6.2

6.2 Function Specify a value derived by the application of a function to an argument.

Format No additional Format items.

Syntax Rules 1)

Replaces SR14)a)

DT shall not be a character string, bit string, an enumerated type, datetime,

or a period type.




WG3:YGJ-016 = X3H2-99-084 6.3

6.3 Function Specify a data conversion.


Syntax Rules 1)

Augments SR6) If the is a , then the valid combinations of TD and SD in a are given by the following table.

SD of EN AN C B D T TS YM DT P ET BO ADT NT BL

of TD EN

AN

VC

FC

VB

FB

D

T

TS

YM

DT

P

ET

BO ADT

NT

CL

BL

Y Y Y N N N N M M N Y N M M N

Y Y Y N N N N N N N N N M M N

Y Y Y Y Y Y Y Y Y Y Y Y M M N


N N Y Y N N N N N N N N M M N

N N Y Y N N N N N N N N M M N

N N Y N Y N Y N N Y N N M M N

N N Y N N Y Y N N N N N M M N

N N Y N Y Y Y N N Y N N M M N

M N Y N N N N Y N N N N M M N

M N Y N N N N N Y N N N M M N

N N Y N Y N Y N N Y N N M M N

Y N Y N N N N N N N Y N M M N

N N Y N N N N N N N N Y M M N

M M M M M M M M M M M M M N N


N N N N N N N N N N N N M N Y

M M M M M M M M M M M M M M M

Where: P

= Period


General Rules 1)

Insert this GR

If TD is a period data type with element type TED and SD is not a period data

type, then Case: a) If SD is character string, then SV is replaced by: TRIM ( BOTH ’ ’ FROM SV )

Case: Scalar expressions

21

WG3:YGJ-016 = X3H2-99-084 6.3 i) If the rules for in Subclause 5.2, ‘‘’’, can be applied to SV to determine a valid value of the data type TD, then TV is that value. ii) Otherwise, an exception condition is raised: data exception — invalid character value for cast. b) Otherwise, TV is the result of: PERIOD [ CAST ( SV AS TED ) , CAST ( SV AS TED ) )

2)

Insert this GR If TD and SD are period data types with element types TED and SED, respectively, then TV is the result of:

PERIOD [ CAST ( BEGIN(SV) AS TED ) , CAST ( END(SV) AS TED ) )

3)

Insert this GR If TD is fixed-length character string, then let LTD be the length in characters of TD. If TD has a , then let CSP be that ; otherwise, let SCP be a zero-length string. Let TL be the largest interger such that TL*2 is less than LTD. TV is the result of:

CAST ( TRIM ( BOTH ’ ’ FROM CAST ( BEGIN (VE) AS CHARACTER(TL) CHARACTER SET CSP ) ) || ’,’ || TRIM ( BOTH ’ ’ FROM CAST ( END (VE) AS CHARACTER(TL) CHARACTER SET CSP ) ) AS TD )

4)

Insert this GR If TD is varying-length character string, then let MLTD be the maximum length in characters of TD. If TD has a , then let CSP be that ; otherwise, let SCP be a zero-length string. Let TL be the largest interger such that TL*2+1 is less than MLTD. TV is the result of:

CAST ( TRIM ( BOTH ’ ’ FROM CAST ( BEGIN (VE) AS CHARACTER(TL) CHARACTER SET CSP ) ) || ’,’ || TRIM ( BOTH ’ ’ FROM CAST ( END (VE) AS CHARACTER(TL) CHARACTER SET CSP ) ) AS TD )


WG3:YGJ-016 = X3H2-99-084 6.4

6.4 Function Specify a value.

Format ::= !! All alternatives from Part 2 of this International Standard | ::= !! All alternatives from Part 2 of this International Standard | | | ::= { PRIOR | NEXT } ::= ::= { BEGIN | END | LAST } ::= ::= INTERVAL [ ] ::=

Syntax Rules 1)

Insert this SR

The data type of shall be a period data type.

2)

Insert this SR If is specified, then let the data type of be DP. DP shall be a data type that is capable of being a period element type. The data type of the result is DP.

3)

Insert this SR If is specified, then the data type of the result is the element type of .

4)

Insert this SR If is specified, then let EDT be the element type of .

a) If EDT is a datetime data type, then shall be specified; let IQ be the . Otherwise, let IQ be . b) Let V1 and V2 be two values of EDT. The data type of the result is the same as the data type of (V1 0 V2) IQ.

Scalar expressions

23

WG3:YGJ-016 = X3H2-99-084 6.4


General Rules 1)

Insert this GR If is specified, then let DT be the data type and let VP be the value of the that it immediately contains.

a) If VP is null, then the result is the null value. Otherwise, Case: i) If PRIOR is specified, then the result VR is that value of DT such that VR < VP and there exists no value NV of DT such that VR < NV < VP. ii) If NEXT is specified, then the result VR is that value of DT such that VP < VR and there exists no value NV of DT such that VP < NV < VR. b) If the type of the result is datetime and, after applying the previous subrule, any datetime field of the result is outside the permissible range of values for the field, or the result is invalid based on the natural rules for dates and times, then an exception condition is raised: data exception — datetime field overflow. 2)

If a is specified, then let P be the result of . If VP is null, then the result is the null value. Otherwise, the result of the is Insert this GR

Case: a) If BEGIN is specified, then the beginning bound of P. b) If END is specified then the ending bound of P. c) If LAST is specified, then the result of PRIOR ( END (P) )

3)

Insert this GR If a is specified, then let P be the result of . The result of the is the value of:

( END(P)

0 BEGIN(P) ) IQ


WG3:YGJ-016 = X3H2-99-084 6.5

6.5 Function Specify an expression whose data type is a period data type.

Format ::= | P_UNION | P_EXCEPT | ::= | P_INTERSECT ::= | ::= | ::= |

Syntax Rules 1) Let P_SETOP be P_UNION, P_EXCEPT, or P_INTERSECT. 2) The data type of the result of P1 P_SETOP P2 is determined by applying the rules of Subclause 9.3, ‘‘Set operation result data types’’, to the data types of P1 and P2. 3) Let P be a , let V be a , and let PAO be a . P PAO V and V PAO P are both equivalent to: PERIOD [ BEGIN(P) PAO V , END(P) PAO V )

4) The data type of shall be a period data type.

Access Rules None.

General Rules 1) The result of S1 P_SETOP S2 is determined as follows: Let MAX(X, Y) denote the greater of X and Y, and let MIN(X, Y) denote the lesser of X and Y, where X and Y denote any two comparable values.

Scalar expressions

25

WG3:YGJ-016 = X3H2-99-084 6.5 Case: a) If P_UNION is specified, then Case: i) If P1 OVERLAPS P2 is not true, then an exception condition is raised: data exception — periods do not overlap. ii) Otherwise the result of P1 P_UNION P2 is: PERIOD [ MIN (BEGIN(P1) , BEGIN(P2) ) , MAX (END(P1) , END(P2) ) )

b) If P_EXCEPT is specified, then, Case: i) If P1 OVERLAPS P2 is not true, then the result is P1. ii) If P1 CONTAINS P2 OR P2 CONTAINS P1 is true, then an exception condition is raised: data exception — invalid period. iii) If BEGIN(P2) < BEGIN(P1), then the result is: PERIOD [ MAX (BEGIN(P1) , END(P2) ) , END(P1) )

iv) Otherwise the result is: PERIOD [ BEGIN(P1) , MIN (BEGIN(P2) , END(P1) ) )

c) If P_INTERSECT is specified, then: i) If P1 OVERLAPS P2 is not true, then an exception condition is raised: data exception — periods do not overlap. ii) Otherwise the result of P1 P_INTERSECT P2 is: PERIOD [ MAX (BEGIN(P1) , BEGIN(P2) ) , MIN (END(P1) , END(P2) ) )


WG3:YGJ-016 = X3H2-99-084 6.6

6.6 Function Specify an expression whose result is of collection type SET or MULTISET.

Format ::= !! All alternatives from Part 2 of this International Standard | | ::= EXPAND

Syntax Rules 1)

Insert this SR The data type of an is SET and its element type is the element type of the immediately contained PVE.


General Rules 1)

Insert this GR The result of is a set whose elements are duplicates of all the elements of PVE, namely every value V of the element type of PVE, such that BEGIN(PVE) V END(PVE).

Scalar expressions

27

WG3:YGJ-016 = X3H2-99-084 6.7

6.7 Function Specify a function returning a value of data type SET(PERIOD).

Format ::= ::= NORMALIZE ::=

Syntax Rules 1) The element type PCET of a shall be a period data type PT. 2) The data type of is SET(PT).

Access Rules None.

General Rules 1) Let PC be the specified in a NPSF. The value returned by NPSF is the result of the following : ( SELECT S_UNION (SET {P}) FROM ( WITH PCT AS ( SELECT DISTINCT P FROM TABLE(PC) AS S(P) ) SELECT DISTINCT PERIOD [ BEGIN(F.P) , END(L.P) ) AS P FROM PCT AS F, PCT AS L WHERE BEGIN(F.P) < END(L.P) AND NOT EXISTS ( SELECT * FROM PCT AS M WHERE BEGIN(F.P) < BEGIN(M.P) AND BEGIN(M.P) < END(L.P) AND NOT EXISTS ( SELECT * FROM PCT AS A1 WHERE BEGIN(A1.P) < BEGIN(M.P) AND BEGIN(M.P) END (P2)

c) If P_COMPOP is MEETS, then the result is: END (P1) = BEGIN (P2) OR BEGIN (P1) = END (P2)

d) If P_COMPOP is CONTAINS, then the result is: BEGIN (P1) = END (P2)


WG3:YGJ-016 = X3H2-99-084

9 Data assignment rules 9.1 Retrieval assignment Function Specify rules for value assignments that retrieve SQL-data.

Syntax Rules 1)

If the data type of T is character string, bit string, numeric, datetime, interval, or period, then the data type of V shall be a mutually assignable character string type, a bit string type, a numeric type, the same datetime type, a comparable interval type, or the same period type, respectively. Augments SR2)


General Rules 1)

Insert this GR If the data type of T is period and there is a representation of the value of V in the data type of T, then the value of T is set to that representation.

Data assignment rules

43

WG3:YGJ-016 = X3H2-99-084 9.2 Store assignment

9.2 Store assignment Function Specify rules for value assignments that store SQL-data.

Syntax Rules 1)

Augments SR2) If the data type of T is character string, bit string, numeric, datetime, interval, or period, then the data type of V shall be a mutually assignable character string type, a bit string type, a numeric type, the same datetime type, a comparable interval type, or the same period type, respectively.


General Rules 1)

If the data type of T is period and there is a representation of the value of V in the data type of T, then the value of T is set to that representation. Insert this GR


WG3:YGJ-016 = X3H2-99-084 9.3 Set operation result data types

9.3 Set operation result data types Function Specify the Syntax Rules and result data types for s and s having set operators.

Syntax Rules 1)

Augments SR3)

Case:

a) If any data type in DTS is PERIOD(ET) for some data type ET, then every data type in DTS shall be a period data type, and the result is a period data type whose element type is determined by applying Subclause 9.3, ‘‘Set operation result data types’’, to the element types of all the data types in DTS.



Data assignment rules

45

WG3:YGJ-016 = X3H2-99-084


WG3:YGJ-016 = X3H2-99-084

10 Schema definition and manipulation 10.1 Function Specify the default for a column or domain.


Syntax Rules 1)

Insert this SR If a is specified and the subject data type is period, then the shall be a and shall be of the same as the subject data type.


General Rules 1)

Insert this GR If the subject data type is period, then the default value inserted in the column descriptor, if the is to apply to a column, is the value of the .

Schema definition and manipulation

47

WG3:YGJ-016 = X3H2-99-084


WG3:YGJ-016 = X3H2-99-084

11 Dynamic SQL **Editor’s Note** The treatment of period types in Dynamic SQL has been noted as a Possible Problem (see Possible Problem TMPRL-015 ), and Mike Sykes suggests that this Clause should be deleted, if only temporarily, perhaps leaving the Clause and Subclause headings as placeholders.

11.1 Description of SQL item descriptor areas Function Specify the identifiers, data types, and codes used in SQL item descriptor areas.

Syntax Rules 1)

TYPE indicates a , DATETIME_INTERVAL_CODE is a code specified in Table 3, ‘‘Codes associated with datetime and period data types in Dynamic SQL’’, and PRECISION is a valid value for the of the indicated period data type. Insert after SR6)m)


General Rules 1)

Augments GR1) Table 2, ‘‘Codes used for SQL data types in Dynamic SQL’’, specifies the codes associated with the SQL data types.

Table 2—Codes used for SQL data types in Dynamic SQL Data Type

Code All alternatives from part 2 of ISO/IEC 9075

PERIOD

2)

18

Table 3, ‘‘Codes associated with datetime and period data types in Dynamic SQL’’, specifies the codes associated with the datetime data types. Augments GR2)

Dynamic SQL

49

WG3:YGJ-016 = X3H2-99-084 11.1 Description of SQL item descriptor areas Table 3—Codes associated with datetime and period data types in Dynamic SQL Datetime Data Type

Code

DATE

1

TIME

2

TIMESTAMP

3

TIME WITH TIME ZONE

4

TIMESTAMP WITH TIME ZONE

5

PERIOD

6

PERIOD WITH TIME ZONE

7


WG3:YGJ-016 = X3H2-99-084 11.2

11.2 Function Set information in an SQL descriptor area.




General Rules a)

Insert after GR4)d) If DIN is TYPE and V indicates PERIOD or PERIOD WITH TIME ZONE, then PRECISION is set to 6 and all other item descriptor area fields are set to implementation-dependent values.

Dynamic SQL

51

WG3:YGJ-016 = X3H2-99-084 11.3

11.3 Function Obtain information about the columns or s contained in a prepared statement or about the columns of the result set associated with a cursor.

Format No additional Format elements.



General Rules 1)

Augments GR8)d)vii) If TYPE indicates a , then LENGTH is set to the length in positions of the period type, DATETIME_INTERVAL_CODE is set to a code as specified in Table 3, ‘‘Codes associated with datetime and period data types in Dynamic SQL’’, to indicate the specified period data type, and PRECISION is set to the , if applicable.

2)

Insert before GR8)d)viii) If TYPE indicates a , then LENGTH is set to the length in positions of the period type, DATETIME_INTERVAL_CODE is set to a code as specified in Table 3, ‘‘Codes associated with datetime and period data types in Dynamic SQL’’, to indicate the specified period data type, and PRECISION is set to the , if applicable.


WG3:YGJ-016 = X3H2-99-084

12 Definition Schema 12.1 DATA_TYPE_DESCRIPTOR base table Function The DATA_TYPE_DESCRIPTOR table has one row for each domain and one row for each column (in each table) that is defined as having a data type rather than a domain. It effectively contains a representation of the data type descriptors.

Definition CREATE TABLE DATA_TYPE_DESCRIPTOR ( Note: A modification is required to the DATA_TYPE_DESCRIPTOR base table; this modification will be easier to specify when the definition of that table in SQL/Foundation has been modified to accommodate collection types. )

Description No additional Description items.

Definition Schema

53

WG3:YGJ-016 = X3H2-99-084


WG3:YGJ-016 = X3H2-99-084

13 Status codes 13.1 SQLSTATE The exception codes associated with the SQLSTATE parameter are extended to support the period data type. Table 4—SQLSTATE class and subclass values Category

Condition

Class

Subcondition

Subclass

22

(no subclass)

000

invalid period format

032

invalid period

033

All alternatives from part 2 of ISO/IEC 9075 X

data exception

Status codes

55

WG3:YGJ-016 = X3H2-99-084


WG3:YGJ-016 = X3H2-99-084

14 Conformance New paragraph

Claims of conformance to this Part of this International Standard shall state:

1) A conformance claim to Part 2 of this International Standard, in Clause 23, "Conformance". 2) The definitions for all elements and actions that this Part of ISO/IEC 9075 specifies as implementation-defined. 3)

Other items as required.

Conformance

57

WG3:YGJ-016 = X3H2-99-084


WG3:YGJ-016 = X3H2-99-084

Annex A (informative) Implementation-defined elements

New paragraph This Annex references those features that are identified in the body of this part of this International Standard as implementation-defined. Insert after second paragraph The term implementation-defined is used to identify characteristics that may differ between implementations, but that shall be defined for each particular implementation.

There are no additional implementation-defined elements.

Implementation-defined elements 59

WG3:YGJ-016 = X3H2-99-084


WG3:YGJ-016 = X3H2-99-084

Annex B (informative) Implementation-dependent elements

New paragraph This Annex references those places where this part of this International Standard states explicitly that the actions of a conforming implementation are implementation-dependent. Insert after second paragraph The term implementation-dependent is used to identify characteristics that may differ between implementations, but that are not necessarily specified for any particular implementation.

Subclause 11.2, ‘‘’’: 1) If V indicates PERIOD or PERIOD WITH TIME ZONE, then PRECISION is set to 6 and all other item descriptor area fields are set to implementation-dependent values.

Implementation-dependent elements 61

WG3:YGJ-016 = X3H2-99-084


WG3:YGJ-016 = X3H2-99-084

Annex C (informative) Deprecated features

New paragraph It is intended that the following features will be removed at a later date from a revised version of this part of this International Standard:

There are no additional deprecated items.

Deprecated features 63

WG3:YGJ-016 = X3H2-99-084

ANSI Only—caused by ISO changes not yet considered by ANSI


WG3:YGJ-016 = X3H2-99-084

Deprecated features 65

WG3:YGJ-016 = X3H2-99-084

Annex D (informative) Incompatibilities with X3.135-1992


New paragraph This part of this International Standard introduces some incompatibilities with the earlier version of Database Language SQL as specified in ISO/IEC 9075:1992. Unless specified in this Annex, features and capabilities of Database Language SQL are compatible with the earlier version of this International Standard.

1) A number of additional s have been added to the language. These s are: — CONTAINS — EXPAND — EXPANDING — MEETS — NORMALIZE — PERIOD — PRECEDES — SUCCEEDS


WG3:YGJ-016 = X3H2-99-084

Annex E (informative) SQL Feature Taxonomy

This Annex describes a taxonomy of features of the SQL language. To be supplied.

SQL Feature Taxonomy 67

Index Index entries appearing in boldface indicate the page where the word, phrase, or BNF nonterminal was defined; index entries appearing in italics indicate a page where the BNF nonterminal was used in a Format; and index entries appearing in roman type indicate a page where the word, phrase, or BNF nonterminal was used in a heading, Function, Syntax Rule, Access Rule, General Rule, Leveling Rule, Table, or other descriptive text.

—A— Ada • 3, 4 ALL • 33 AND • 15, 27, 28, 35, 42, 66 AS • 22, 28, 32, 35 assignable • 14, 43, 44 assignment • 9, 43, 44 associated with • 49, 52, 55 ATTRIBUTES • 8, 49, 55

—B— based on • 3, 8, 24 base table • 53 BEGIN • 13, 14, 22, 23, 24, 25, 26, 27, 28, 38, 41, 42 beginning bound • 5, 13, 14, 24, 29, 30, 39 • 29 • 17, 29 • 17 bit string type • 43, 44 BNF nonterminal symbol • 6, 7 BOTH • 21

—C— C • 3, 4 • 45 CAST • 22 • 21 • 21 character • 20, 21, 22, 43, 44, 59, 61 CHARACTER • 22 character set • 22 • 22 COBOL • 3, 4 collection • 5, 27, 28, 53 collection type • 27, 53 column • 8, 13, 31, 34, 35, 47, 52, 53 • 34 • 35 • 17, 29, 31, 34 comparable • 14, 25, 29, 38, 39, 41, 43, 44 • 38 compatible • 14, 66

condition • 22, 24, 26, 30, 37, 55 conforming SQL-implementation • 1 constructed • 29 contain • 3, 5, 6, 8, 13, 14, 17, 18, 19, 24, 27, 31, 34, 52, 53 contained in • 6, 31, 34, 52 containing • 5, 8, 13 contains • 14, 17, 24, 53 CONTAINS • 15, 26, 41, 42, 66 • 33 corresponds to • 35 CREATE • 53 current • 3

—D— Data • 1, 3, 4, 11, 43, 49, 50, 66 data exception • 22, 24, 26, 30, 55 data type • 1, 5, 13, 14, 19, 21, 22, 23, 24, 25, 27, 28, 29, 31, 34, 38, 39, 41, 43, 44, 45, 47, 49, 52, 53, 55 • 19, 21 DATA_TYPE • 53 DATA_TYPE_DESCRIPTOR • 53 date • 5, 10, 13, 17, 18, 19, 20, 23, 24, 39, 43, 44, 49, 52, 53, 63 DATE • 17, 50 datetime field overflow • 24 datetime type • 43, 44 • 39 DATETIME_INTERVAL_CODE • 49, 52 • 17, 18 • 47 • 15 dependent • 51, 61 depends on • 6 describe • 1, 5, 6, 10, 13, 52, 67 Description • 7, 49, 53 descriptor • 10, 13, 47, 49, 51, 53, 61 DESCRIPTOR • 53 descriptor area • 49, 51, 61 distinct • 14 DISTINCT • 28

Index 1

WG3:YGJ-016 = X3H2-99-084

domain • 47, 53 duplicate • 13, 27 duplicates • 13, 27 • 52

—E— **Editor’s Note** • 33, 34, 49 effective • 8, 38, 53 effectively • 8, 38, 53 elements • 5, 13, 15, 27, 39, 52, 57, 59, 61 element type • 5, 13, 14, 21, 22, 23, 27, 28, 29, 38, 39, 41, 45 empty • 17, 31, 35 END • 13, 14, 22, 23, 24, 25, 26, 27, 38, 42 ending bound • 5, 13, 14, 24, 29, 30, 39 • 29 • 17, 29 • 17 EXCEPT • 33 exception • 22, 24, 26, 30, 55 exception condition • 22, 24, 26, 30 EXISTS • 28 EXPAND • 15, 27, 35, 66 • 27 EXPANDING • 15, 34, 66 • 33, 34 • 34

—F— fields • 51, 61 fixed-length • 22 Fortran • 3, 4 FORTRAN • 3 FROM • 21, 22, 28, 32, 35

—G— • 17 granule • 5, 13

—M— match • 6 MAX • 25, 26 meets • 13, 14 MEETS • 15, 40, 41, 42, 66 MIN • 25, 26 • 17, 25 modified • 6, 7, 8, 53 • 6 module • 4 MUMPS • 3, 4

—N— NEXT • 23, 24, 29 • 33 • 33 • 33 • 15 NORMALIZE • 13, 15, 28, 31, 32, 35, 66 • 13, 31 • 31, 33 • 28 • 31 no subclass • 55 NOT • 28, 40 null • 17, 24, 29, 30, 39, 41, 42 null value • 17, 24, 29, 39, 41, 42

—O— —I—

identified • 6, 7, 59 identifier • 11, 49 identify • 34, 59, 61 immediate • 6, 19, 24, 27, 31 immediately contain • 19, 24, 27, 31 implementation-defined • 57, 59 implementation-dependent • 51, 61 include • 1, 7, 13 instance • 7 INTERSECT • 25, 26, 33 INTERVAL • 23, 39, 49, 52 • 23 invalid • 22, 24, 26, 30, 55 invalid character value for cast • 22 invalid period format • 55 • 31, 34

2

—L— LAST • 13, 14, 23, 24 last element • 5 • 17, 29 • 17, 19, 23, 27, 28, 34 LENGTH • 52 • 17, 22, 47

object • 8, 11 ON • 31, 35 OR • 26, 28, 40, 42 order • 5, 6, 14 overlaps • 9, 14, 37, 39, 40 OVERLAPS • 26, 39 • 39 • 39 • 39 • 39, 40

—P— parameter • 52, 55 Part 1 • 4, 5 Part 2 • 4, 5, 15, 17, 19, 23, 27, 37, 57 Part 3 • 4 Part 4 • 4 Part 5 • 4, 5 Part 6 • 4 part of • 6, 7, 8, 9, 10, 59, 61, 63, 66 Pascal • 3, 4


WG3:YGJ-016 = X3H2-99-084

period • 1, 5, 8, 9, 13, 14, 15, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 34, 37, 38, 39, 41, 42, 43, 44, 45, 47, 49, 52, 55 PERIOD • 1, 5, 13, 15, 17, 18, 19, 22, 25, 26, 28, 29, 35, 39, 41, 42, 45, 49, 50, 51, 61, 66 • 25 • 25 • 23, 24 • 17 • 28 • 41, 42 • 23, 24 • 17, 18, 47 • 41 • 41 • 41 • 37, 41 • 25 • 27, 28 • 25 period type • 19, 20, 43, 44, 49, 52 • 19, 49, 52 • 25, 29 • 23, 24 • 23, 24 • 23, 25, 27, 39, 41 permitted • 13 PL/I • 3, 4 • 25 precede • 14 precedes • 14 PRECEDES • 15, 40, 41, 42, 66 precision • 5, 13, 47, 49, 52 PRECISION • 49, 51, 52, 61 predefined • 19 • 19 • 37 prepared • 52 PRIOR • 23, 24, 29 • 23, 24 • 23, 24

—Q— query • 28, 31, 33, 45 • 33, 45 • 33 • 31 • 33 • 17

—R— • 15, 66 respective values • 38 result data type • 45 result set • 52 Retrieval assignment • 43 • 17 • 17, 19, 23, 27, 28, 29, 34 row • 8, 13, 14, 38, 39, 53 row type • 14

• 39

—S— • 28 scope • 1, 6, 8 Scope • 1 SELECT • 28, 32, 35 • 31, 34, 52 • 15 sequence • 31, 34, 35 SET • 27, 28 • 51 • 20 set operator • 45 • 27, 28 shall • 6, 17, 18, 19, 20, 23, 25, 28, 29, 31, 34, 38, 39, 41, 43, 44, 45, 47, 57, 59 significant • 6 SIMPLE • 3, 18, 21, 22, 24, 25, 26, 28, 31, 32, 35, 38, 39, 40, 42 • 33 • 17, 23 specified by • 7 specify • 6, 7, 33, 34, 53 SQL-data • 43, 44 SQL-implementation • 1 SQLSTATE • 55 STATE • 55 Store assignment • 44 SUCCEEDS • 15, 40, 41, 42, 66

—T— table • 5, 6, 7, 8, 10, 13, 21, 31, 33, 34, 53 TABLE • 28, 35, 53

• 13 Tables • 7 TIME • 13, 18, 50, 51, 61 TIMESTAMP • 13, 17, 50 • 17, 18 • 17 TM • 49 • 15 TRIM • 21, 22 type • 1, 5, 8, 9, 10, 13, 14, 19, 20, 21, 22, 23, 24, 25, 27, 28, 29, 30, 31, 34, 38, 39, 41, 43, 44, 45, 47, 49, 52, 53, 55 Type • 49, 50 TYPE • 51 types • 1, 10, 14, 22, 25, 29, 38, 39, 43, 44, 45, 49, 53

—U— UNION • 25, 26, 28, 32, 33

—V— valid • 3, 21, 22, 24, 26, 30, 39, 49, 55 Value • 14 • 21, 23, 25, 29, 31, 34, 35, 41 • 23, 25

Index 3

WG3:YGJ-016 = X3H2-99-084

—W— WHERE • 28 WITH • 13, 28, 32, 35, 50, 51, 61

—Z— ZONE • 13, 50, 51, 61

4


Report "SQL/Temporal"

Your name

Email

Reason

Description

Copyright © 2025 M.MOAM.INFO. All rights reserved.
| About Us | Privacy Policy | Terms of Service | Help | Copyright | Contact Us | Cookie Policy

Sign In

Email

Password

Remember me Forgot password?

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close