Syntax
Informi x Extended Parall el Server, Version 8.3 Informix Dynamic
Server.2000, Version 9.2
December 1999 Part No. 000-6527
ii Informi x Guide to SQL: Syntax
Published by Informix® Press Informix Corporation 4100
Bohannon Drive Menlo Park, CA 94025-1032
© 1999 Informix Corporation. All rights reserved. The following are
trademarks of Informix Corporation or its affiliates, one or more
of which may be registered in the United States or other
jurisdictions:
Answers OnLineTM; C-ISAM®; Client SDKTM; DataBlade®; Data
DirectorTM; Decision FrontierTM;
Dynamic Scalable ArchitectureTM; Dynamic ServerTM; Dynamic
ServerTM, Developer EditionTM;
Dynamic ServerTM with Advanced Decision Support OptionTM;
Dynamic ServerTM with Extended
Parallel OptionTM; Dynamic ServerTM with MetaCube®; Dynamic
ServerTM with Universal Data OptionTM;
Dynamic ServerTM with Web Integration OptionTM; Dynamic
ServerTM, Workgroup EditionTM;
Dynamic Virtual MachineTM; Extended Parallel ServerTM; FormationTM;
Formation ArchitectTM;
Formation Flow EngineTM; Gold Mine Data Access®; IIF.2000TM;
i.ReachTM; i.SellTM; Illustra®; Informix®;
Informix® 4GL; Informix® InquireSM; Informix® Internet
Foundation.2000TM; InformixLink®;
Informix® Red Brick® Decision ServerTM; Informix Session
ProxyTM; Informix® VistaTM; InfoShelf TM;
InterforumTM; I-SpyTM; MediazationTM; MetaCube®; NewEraTM;
ON-BarTM; OnLine Dynamic ServerTM;
OnLine/Secure Dynamic ServerTM; OpenCase®; OrcaTM; PaVERTM; Red
Brick® and Design;
Red Brick® Data MineTM; Red Brick® Mine BuilderTM; Red
Brick® DecisionscapeTM; Red Brick® ReadyTM;
Red Brick Systems®; Regency Support®; Rely on Red BrickSM; RISQL®;
Solution DesignSM; STARindexTM;
STAR joinTM; SuperView®; TARGETindexTM; TARGET joinTM;
The Data Warehouse Company®;
The one with the smartest data wins.TM; The world is being
digitized. We’re indexing it.SM;
Universal Data Warehouse BlueprintTM; Universal Database
ComponentsTM; Universal Web ConnectTM;
ViewPoint®; VisionaryTM; Web Integration SuiteTM. The Informix logo
is registered with the United States
Patent and Trademark Office. The DataBlade logo is registered with
the United States Patent and
Trademark Office.
Documentation Team: Linda Briscoe, Evelyn Eldridge, Kathy Schaefer
Francis, Mary Kraemer, Barbara Nomiyama, Tom Noronha, Elaina Von
Haas, Richelle White
GOVERNMENT LICENSE RIGHTS
Software Dependencies . . . . . . . . . . . . . . . 4
Demonstration Databases . . . . . . . . . . . . . . 5
New Features in Version 9.2 . . . . . . . . . . . . . 8
Documentation Conventions . . . . . . . . . . . . . . 10
Typographical Conventions . . . . . . . . . . . . . 11
Icon Conventions . . . . . . . . . . . . . . . . . 12
Syntax Conventions . . . . . . . . . . . . . . . . 14
Sample-Code Conventions . . . . . . . . . . . . . . 19
Printed Manuals . . . . . . . . . . . . . . . . . 20
On-Line Help . . . . . . . . . . . . . . . . . . 20
Related Reading . . . . . . . . . . . . . . . . . 22
Chapter 1 Overview of SQL Syntax
In This Chapter . . . . . . . . . . . . . . . . . . . 1-3
Categories of SQL Statements . . . . . . . . . . . . . . 1-9
ANSI Compliance and Extensions . . . . . . . . . . . . 1-13
Chapter 2 SQL Statements
ALLOCATE DESCRIPTOR . . . . . . . . . . . . . 2-8
ALLOCATE ROW . . . . . . . . . . . . . . . . 2-10
ALTER FRAGMENT . . . . . . . . . . . . . . . 2-12
ALTER FUNCTION . . . . . . . . . . . . . . . . 2-41
ALTER INDEX . . . . . . . . . . . . . . . . . 2-44
ALTER PROCEDURE . . . . . . . . . . . . . . . 2-48
ALTER ROUTINE . . . . . . . . . . . . . . . . 2-51
ALTER TABLE . . . . . . . . . . . . . . . . . 2-55
BEGIN WORK. . . . . . . . . . . . . . . . . . 2-91
SELECT . . . . . . . . . . . . . . . . . . . . 2-634
SET DATASKIP . . . . . . . . . . . . . . . . . 2-709
SET DEFERRED_PREPARE . . . . . . . . . . . . . 2-715
SET DESCRIPTOR . . . . . . . . . . . . . . . . 2-719
SET EXPLAIN . . . . . . . . . . . . . . . . . . 2-730
SET ISOLATION . . . . . . . . . . . . . . . . . 2-736
In This Chapter . . . . . . . . . . . . . . . . . . . 3-3 CALL . .
. . . . . . . . . . . . . . . . . . . 3-4
CASE . . . . . . . . . . . . . . . . . . . . . 3-7
CONTINUE . . . . . . . . . . . . . . . . . . 3-10
DEFINE . . . . . . . . . . . . . . . . . . . . 3-11
EXIT . . . . . . . . . . . . . . . . . . . . . 3-24
FOR . . . . . . . . . . . . . . . . . . . . . 3-26
FOREACH . . . . . . . . . . . . . . . . . . . 3-30
IF . . . . . . . . . . . . . . . . . . . . . . 3-37
LET . . . . . . . . . . . . . . . . . . . . . 3-41
In This Chapter . . . . . . . . . . . . . . . . . . 4-3 Argument. .
. . . . . . . . . . . . . . . . . 4-6
Collection Derived Table . . . . . . . . . . . . . 4-9
Index
Software Dependencies . . . . . . . . . . . . . . . . 4
Demonstration Databases . . . . . . . . . . . . . . . 5
New Features . . . . . . . . . . . . . . . . . . . . . 6 New
Features in Version 8.3 . . . . . . . . . . . . . . 6
Performance Enhancements . . . . . . . . . . . . . 6 New SQL
Functionality . . . . . . . . . . . . . . 6 Version 8.3 Features
from Version 7.30 . . . . . . . . . 7
New Features in Version 9.2 . . . . . . . . . . . . . . 8
Extensibility Enhancements . . . . . . . . . . . . . 8 Performance
Improvements . . . . . . . . . . . . . 9 Special Features . . . . .
. . . . . . . . . . . . 9 Version 9.2 Features from Dynamic Server
7.30 . . . . . . 9
Documentation Conventions . . . . . . . . . . . . . . . 10
Typographical Conventions . . . . . . . . . . . . . . 11
Icon Conventions . . . . . . . . . . . . . . . . . . 12
Comment Icons . . . . . . . . . . . . . . . . . 12 Feature,
Product, and Platform Icons . . . . . . . . . . 12 Compliance Icons
. . . . . . . . . . . . . . . . 14
Syntax Conventions . . . . . . . . . . . . . . . . . 14
Elements That Can Appear on the Path . . . . . . . . . 15 How to
Read a Syntax Diagram . . . . . . . . . . . . 18
Sample-Code Conventions . . . . . . . . . . . . . . . 19
Printed Manuals . . . . . . . . . . . . . . . . . . 20
On-Line Help . . . . . . . . . . . . . . . . . . . 20
Related Reading . . . . . . . . . . . . . . . . . . 22
In This Introduction
This Introduction provides an overview of the information in this
manual and describes the conventions it uses.
About This Manual
This manual contains all the syntax descriptions for structured
query language (SQL) and Stored Procedure Language (SPL) statements
for Version 9.2 of Informix Dynamic Server 2000 and Version 8.3 of
Informix Extended Parallel Server.
This manual is a companion volume to the Informix Guide to SQL:
Reference, the Informix Guide to SQL: Tutorial, and the Informix
Guide to Database Design and Implementation. The Informix Guide to
SQL: Reference provides reference information for aspects
of SQL other than the language statements. The Informix
Guide to SQL: Tutorial shows how to use basic and advanced SQL and
SPL routines to access and manipulate the data in your
databases. The Informix Guide to Database Design and Implementation
shows how to use SQL to implement and manage your databases.
Types of Users
Database users
Database administrators
Database-application programmers
Software Dependencies
This manual assumes that you have the following background:
A working knowledge of your computer, your operating system, and
the utilities that your operating system provides
Some experience working with relational databases or exposure to
database concepts
Some experience with computer programming
If you have limited experience with relational databases, SQL, or
your operating system, refer to the Getting Started manual for your
database server for a list of supplementary titles.
Software Dependencies
This manual assumes that you are using one of the following
database servers:
Informix Extended Parallel Server, Version 8.3
Informix Dynamic Server 2000, Version 9.2
Assumptions About Your Locale
Informix products can support many languages, cultures, and code
sets. All culture-specific information is brought together in a
single environment, called a Global Language Support (GLS)
locale.
This manual assumes that you use the U.S. 8859-1 English locale as
the default locale. The default is en_us.8859-1 (ISO 8859-1)
on UNIX platforms or en_us.1252 (Microsoft 1252) for Windows
NT environments. This locale supports U.S. English format
conventions for dates, times, and currency, and also supports the
ISO 8859-1 or Microsoft 1252 code set, which includes the
ASCII code set plus many 8-bit characters such as é, è, and
ñ.
If you plan to use nondefault characters in your data or your SQL
identifiers, or if you want to conform to the nondefault collation
rules of character data, you need to specify the appropriate
nondefault locale.
For instructions on how to specify a nondefault locale, additional
syntax, and other considerations related to GLS locales, see
the Informix Guide to GLS Functionality.
Demonstrat ion Databases
The DB-Access utility, which is provided with your Informix
database server products, includes one or more of the following
demonstration databases:
The stores_demo database illustrates a relational schema with
infor- mation about a fictitious wholesale sporting-goods
distributor. Many examples in Informix manuals are based on
the stores_demo database.
The sales_demo database illustrates a dimensional schema for data-
warehousing applications. For conceptual information about dimen-
sional data modeling, see the Informix Guide to Database Design and
Implementation. ♦
The superstores_demo database illustrates an object-relational
schema. The superstores_demo database contains examples
of extended data types, type and table inheritance, and
user-defined routines. ♦
For information about how to create and populate the demonstration
databases, see the DB-Access User’s Manual. For descriptions of the
databases and their contents, see the Informix Guide to SQL:
Reference.
The scripts that you use to install the demonstration databases
reside in the $INFORMIXDIR /bin directory on
UNIX platforms and in the %INFORMIXDIR%\bin directory in
Windows environments.
New Features
New Features
For a comprehensive list of new database server features, see the
release notes. This section lists new features relevant to this
manual.
New Features in Version 8. 3
This manual describes new features in Version 8.3 of Extended
Parallel Server. The features fall into the following areas:
Performance enhancements
Performance Enhancements
This manual describes the following performance enhancements to
Version 8.3 of Extended Parallel Server:
Insert cursors with simple large objects
Coarse-grain index locks
Index on aggregates
New SQL Functionali ty
This manual describes the following new SQL functionality in
Version 8.3 of Extended Parallel Server:
CASE statement in Stored Procedure Language (SPL)
Creating a table with RANGE fragmentation
DELETE…USING statement to delete rows based on a table
join
Globally detached indexes
MIDDLE function
TRUNCATE statement
Version 8.3 Features from Version 7.30
This manual describes the following features from Version 7.3 of
Dynamic Server in Version 8.3 of Extended Parallel Server:
Ability to retain update locks
ALTER FRAGMENT attach with remainders
ALTER TABLE to add or drop a foreign key constraint
ALTER TABLE to add, drop, or modify a column
Constraints on columns other than the fragmentation column
COUNT function
DBINFO provides all Version 7.3 information and adds the
coserver ID and dbspace name
Deferred constraints for all constraint types
Deferred referential-integrity constraints
RENAME COLUMN statement
Triggers
Memory-resident tables
Violations table
New Features in Version 9.2
New Features in Version 9. 2
This manual describes new features in Version 9.2 of Dynamic
Server. The features fall into the following areas:
Extensibility enhancements
Performance improvements
Special features
Extensibility Enhancements
This manual describes the following extensibility enhancements to
Version 9.2 of Dynamic Server:
General enhancements to SQL:
Triggers on SELECT statements
Round-robin fragmentation for smart large objects
ALTER TABLE for smart large objects
Enhancements to collections:
Collection-derived tables
Collection subqueries
GRANT, REVOKE UNDER on row types
Enhancements to user-defined routines (UDRs):
GRANT, REVOKE on UDR external languages
ALTER FUNCTION, PROCEDURE, ROUTINE statements
User-defined aggregates
Performance I mprovements
This manual describes the following performance improvements to
Version 9.2 of Dynamic Server:
For SQL:
Special Features
This manual describes the following special features of Version 9.2
of Dynamic Server:
Long identifiers:
128-character identifier
Version 9. 2 Feat ures from Dynamic Server 7. 30
This manual also describes features first released in Version 7.30.
These features fall into the following areas:
Reliability, availability, and serviceability:
Performance:
Documentation Conventions
Application migration:
UPPER, LOWER, and INITCAP functions for case-insensitive
search (for built-in types)
REPLACE, SUBSTR, LPAD, and RPAD functions for string manip-
ulation (for built-in types)
UNION operator in CREATE VIEW statement
CASE expression
EXECUTE PROCEDURE syntax to update triggering columns
New arguments to the dbinfo() function to obtain the hostname and
version of the database server
Documentation Conventions
This section describes the conventions that this manual uses. These
conventions make it easier to gather information from this and
other volumes in the documentation set.
The following conventions are discussed:
Typographical conventions
Icon conventions
Syntax conventions
Sample-code conventions
Typographica l Convent ions
This manual uses the following conventions to introduce new terms,
illustrate screen displays, describe command syntax, and so
forth.
Tip: When you are instructed to “enter” characters or to
“execute” a command, immediately press RETURN after the entry.
When you are instructed to “type” the text or to “press” other
keys, no RETURN is required.
Convention M eaning
KEYWORD All primary elements in a programming language statement
(keywords) appear in uppercase letters in a serif font.
italics i ta l ics
italics
Within text, newterms and emphasized words appear in italics.
Within syntax and code examples, variable values that you are to
specify appear in italics.
boldface boldface
Names of program entities (such as classes, events, and tables),
environment variables, file and pathnames, and interface elements
(such as icons, menu items, and buttons) appear in
boldface.
monospace monospace
Information that the product displays and information that you
enter appear in a monospace typeface.
KEYSTROKE Keys that you are to press appear in uppercase letters in
a sans serif font.
Icon Conventions
Icon Convent ions
Throughout the documentation, you willfind text that is identified
by several different types of icons. This section describes these
icons.
Comment Icons
Comment icons identify three types of information, as the following
table describes. This information always appears in italics.
Feature, Product, and Platform Icons
Feature, product, and platform icons identify paragraphs that
contain feature-specific, product-specific, or platform-specific
information.
Icon Label Description
Warning: Identifies paragraphs that contain vital
instructions, cautions, or critical information
Important: Identifies paragraphs that contain significant
information about the feature or operation that is being
described
Tip: Identifies paragraphs that offer additional details or
shortcuts for the functionality that is being described
Icon Description
Identifies information that is specific to C user-defined routines
(UDRs)
Identifies information that is specific to DB-Access
Identifies information that is specific to Informix ESQL/C
(1 of 2)
Introduction 13
Icon Conventions
These icons can apply to an entire section or to one or more
paragraphs within a section. If an icon appears next to a section
heading, the information that applies to the indicated feature,
product, or platform ends at the next heading at the same or higher
level. A♦ symbol indicates the end of feature-, product-, or
platform-specific information that appears in one or more
paragraphs within a section.
Identifies information that is specific to external routines, that
is, UDRs written in both C and Java.
Identifies information that relates to the Informix Global Language
Support (GLS) feature
Identifies information that is specific to Informix Dynamic Server
2000
Identifies information that is specific to UDRs written in
Java
Identifies information that is specific to SQL Editor, which is a
component of Informix Enterprise Command Center for Dynamic
Server
Identifies information that is specific to UNIX platforms
Identifies information that is specific to the Windows NT
environment
Identifies information or syntax that is specific to Informix
Extended Parallel Server
Icon Description
Syntax Conventions
Compliance Icons
Compliance icons indicate paragraphs that provide guidelines
forcomplying with a standard.
These icons can apply to an entire section or to one or more
paragraphs within a section. If an icon appears next to a section
heading, the information that applies to the indicated feature,
product, or platform ends at the next heading at the same or higher
level. A♦ symbol indicates the end of feature-, product-, or
platform-specific information that appears within one or more
paragraphs within a section.
Syntax Conventions
This section describes conventions for syntax diagrams. Each
diagram displays the sequences of required and optional keywords,
terms, and symbols that are valid in a given statement or segment,
as Figure 1 shows.
Each syntax diagram begins at the upper-left corner and ends at the
upper- right corner with a vertical terminator. Between these
points, any path that does not stop or reverse direction describes
a possible form of the statement.
Icon Description
Identifies functionality that conforms to X/Open
Identifies information or syntax that is an Informix extension to
ANSI SQL-92 entry-level standard SQL
ANSI
X/O
SET LOG
Introduction 15
Syntax Conventions
Syntaxelements in a path represent terms, keywords, symbols, and
segments that can appear in your statement. The path always
approaches elements from the left and continues to the right,
except in the case of separators in loops. For separators in loops,
the path approaches counterclockwise. Unless otherwise noted, at
least one blank character separates syntax elements.
Elements That Can Appear on the Pa th
You might encounter one or more of the following elements on a
path.
Element Description
KEYWORD A word in UPPERCASE letters is a keyword. You must spell
the word exactly as shown; however, you can use either uppercase or
lowercase letters.
( . , ; @ + * - / ) Punctuation and other nonalphanumeric
characters are literal symbols that you must enter exactly as
shown.
' ' Single quotes are literal symbols that you must enter as
shown.
variable A word in italics represents a value that you must supply.
A table immediately following the diagram explains the value.
A reference in a box represents a subdiagram. Imagine that the
subdiagram is spliced into the main diagram at this point. When a
page number is not specified, the subdiagram appears on the same
page.
A reference in a box in the upper-right corner of a subdiagram
refers to the next higher-level diagram of which this
subdiagram is a member.
An icon is a warning that this path is valid only for some
products, or only under certain conditions. Characters on the icons
indicate what products or conditions support the path.
These icons might appear in a syntax diagram:
(1 of 3)
E/C
Syntax Conventions
This path is valid only for C user-defined routines (UDRs).
This path is valid only for DB-Access.
This path is valid only for Informix ESQL/C.
This path is valid only for external routines, that is, UDRs
written in C and Java.
This path is recommended only if you use a nonde- fault
locale.
This path is valid only for UDRs written in Java.
This path is valid only for Dynamic Server.
This path is validonly if you are using Informix Stored Procedure
Language (SPL).
This path is valid only for Extended Parallel Server.
This path is an Informix extension to ANSI SQL-92 entry-level
standard SQL. If you initiate Informix extension checking and
include this syntax branch, you receive a warning. If you have set
the DBANSIWARN environment variable at compile time, or have used
the -ansi compile flag, you receive warnings at compile time.
If you have DBANSIWARN
set at runtime, or if you compiled with the -ansi flag,
warning flags are set in the sqlwarn structure. The
Informix extension warnings tend to be conservative. Sometimes the
warnings appear even when a syntax path conforms to the
ANSI standard.
Element Description
Syntax within a pair of arrows is a subdiagram.
The vertical line terminates the syntax diagram.
A branch below the main path indicates an optional path. (Any term
on the main path is required, unless a branch can circumvent
it.)
A set of multiple branches indicates that a choice among more than
two different paths is available.
A loop indicates a path that you can repeat. Punctuation along the
top of the loop indicates the separator symbol for list items. If
no symbol appears, a blank space is the separator.
A gate ( ) on a path indicates that you can only use that path the
indicated number of times, even if it is part of a larger loop. You
can specifysize no more than three times within this statement
segment.
Element Description
Syntax Conventions
How to Read a Syntax Diagram
Figure 2 shows a syntax diagram that uses most of the path elements
that the previous table lists.
To use this diagram to construct a statement, start at the top left
with the keyword DELETE FROM. Follow the diagram to the right,
proceeding through the options that you want.
Figure 2 illustrates the following steps:
1. Type DELETE FROM.
2. You can delete a table, view, or synonym:
Type the table name, view name, or synonym, as you desire.
You can type WHERE to limit the rows to delete.
If you typeWHERE and you are using DB-Access or the SQL Editor, you
must include the Condition clause to specify a condition to delete.
To find the syntax for specifying a condition, go to the
“Condition” segment on the specified page.
If you are using ESQL/C, you can include either the Condition
clause to delete a specific condition or the CURRENT OF cursor
clause to delete a row from the table.
3. Follow the diagram to the terminator.
Your DELETE statement is complete.
Figure 2 Example of a Syntax Diagram
Condition p. 4-5
Sample-Code Convent ions
Examples of SQL code occur throughout this manual. Except
where noted, the code is not specific to any single Informix
application development tool. If only SQL statements are
listed in the example, they are not delimited by semicolons. For
instance, you might see the code in the following example:
CONNECT TO stores_demo ...
...
COMMIT WORK DISCONNECT CURRENT
To use this SQL code for a specific product, you must apply
the syntax rules for that product. For example, if you are using
DB-Access, you must delimit multiple statements with semicolons. If
you are using an SQL API, you must use EXEC SQL at the start of
each statement and a semicolon (or other appro- priate delimiter)
at the end of the statement.
Tip: Ellipsis points in a code example indicate that more
code would be added in a full application, but it is not
necessary to show it to describe the concept being discussed.
For detailed directions on using SQL statements for a
particular application development tool or SQL API, see the manual
for your product.
Additional Documentat ion
For additional information, you might want to refer to the
following types of documentation:
On-line manuals
Printed manuals
On-line help
Related reading
On- Line Manuals
On-Line M anuals
An Answers OnLine CD that contains Informix manuals in electronic
format is provided with your Informix products. You can install the
documentation or access it directly from the CD. For information
about how to install, read, and print on-line manuals, see the
installation insert that accompanies Answers OnLine.
Informix on-line manuals are also available on the following Web
site:
www.informix.com/answers
To order printed manuals, call 1-800-331-1763 or send email to
[email protected]. Please provide the following information
when you place your order:
The documentation that you need
The quantity that you need
Your name, address, and telephone number
On-Line Help
Informix provides on-line help with each graphical user interface
(GUI) that displays information about those interfaces and the
functions that they perform. Use the help facilities that each GUI
provides to display the on-line help.
Error Message Documentation
Informix software products provide ASCII files that contain
all of the Informix error messages and their corrective
actions.
WIN NT
Documentation Notes, Release Notes, M achine Notes
To read error messages and corrective actions on UNIX, use one of
the following utilities.
To read error messages and corrective actions in Windows
environments, use the Informix Find Error utility. To
display this utility, choose StartProgramsInformix from the Task
Bar. ♦
Instructions for using the preceding utilities are available in
Answers OnLine. Answers OnLine also provides a listing of error
messages and corrective actions in HTML format.
Documentation Notes, Release Notes, Machine Notes
In addition to printed documentation, the following sections
describe the on- line files that supplement the information in this
manual. Please examine these files before you begin using your
database server. They contain vital information about application
and performance issues.
On UNIX platforms, the following on-line files appear in the
$INFORMIXDIR /release/en_us/0333 directory. Replace
x.y in the filenames with the version number of your database
server.
Util ity Description
♦
On- Line Fil e Purpose
SQLDOC_x.y The documentation-notes file for your version of
this manual describes topics that are not covered in the manual or
that were modified since publication.
SERVERS_x.y The release-notes file describes feature
differences from earlier versions of Informix products and how
these differences might affect current products.
Thisfilealsocontains information about any known problems and their
workarounds.
IDS_9.2 or XPS_x.y
The machine-notes file describes any special actions that you must
take to configure and use Informix products on your computer.
Machine notes are named for the product described.
UNIX
Related Reading
The following items appear in the Informix folder. To
display this folder, choose StartProgramsInformix from the
Task Bar.
Machine notes do not apply to Windows environments. ♦
Rela ted Reading
For a list of publications that provide an introduction to database
servers and operating-system platforms, refer to your Getting
Started manual.
Compliance with Industry Standards
The American National Standards Institute (ANSI) has established a
set of industry standards for SQL. Informix SQL-basedproducts
are fully compliant with SQL-92 Entry Level (published as ANSI
X3.135-1992), which is identical to ISO 9075:1992. In
addition, many features of Informix database servers comply with
the SQL-92 Intermediate and Full Level and X/Open SQL
CAE
(common applications environment) standards.
Progra m Group I te m De sc ri pt ion
Documentation Notes This item includes additions or corrections to
manuals, along with information about features that might not be
covered in the manualsor that havebeenmodified since
publication.
Release Notes This item describes feature differences from earlier
versions of Informix products and how these differ- ences might
affect current products. This file also contains information about
any known problems and their workarounds.
WIN NT
Informix Welcomes Your Comments
Informix Welcomes Your Comments
Let us know what you like or dislike about our manuals. To help us
with future versions of our manuals, we want to know about any
corrections or clarifications that you would find useful. Include
the following information:
The name and version of the manual that you are using
Any comments that you have about the manual
Your name, address, and phone number
Send electronic mail to us at the following address:
[email protected]
The doc alias is reserved exclusively forreporting errors
andomissions in our documentation.
We appreciate your suggestions.
Categories of SQL Statements . . . . . . . . . . . . . . .
1-9
ANSI Compliance and Extensions . . . . . . . . . . . . . 1-13
In This Chapter
This chapter provides information about how to use the SQL
statements, SPL
statements, and segments that are discussed in the later chapters
of this book. It is organized into the following sections.
Section Starting Page Scope
“How to Enter SQL Statements”
1-4 This section shows how to use the statement diagrams and
descriptions to enter SQL statements correctly.
“How to Enter SQL Comments”
1-6 This section shows how to enter comments for SQL
statements.
“CategoriesofSQL Statements”
“ANSI Compliance and Extensions”
How to Enter SQL Statements
How to Ente r SQL Sta te ments
The purpose of the statement descriptions in this manual is to help
you to enter SQL statements successfully. Each statement
description includes the following information:
A brief introduction that explains the purpose of the
statement
A syntax diagram that shows how to enter the statement
correctly
A syntax table that explains each input parameter in the syntax
diagram
Rules of usage, including examples that illustrate these
rules
If a statement consists of multiple clauses, the statement
description provides the same set of information for each
clause.
Each statement description concludes with references to related
information in this manual and other manuals.
The major aids for entering SQL statements include:
the combination of the syntax diagram and syntax table.
the examples of syntax that appear in the rules of usage.
the references to related information.
Using Syntax Diagrams and Syntax Tables
Before you try to use the syntax diagrams in this chapter, it is
helpful to read the “Syntax Conventions” on page 14 of the
Introduction. This section is the key to understanding the syntax
diagrams in the statement descriptions.
How to Enter SQL Statements
When a syntax diagram within a statement description includes input
parameters, the syntax diagram is followed by a syntax table that
shows how to enter the parameters without generating errors. Each
syntax table includes the following columns:
The Elements column lists the name of each parameter as it
appears in the syntax diagram.
The Purpose column briefly states the purpose of the
parameter. If the parameter has a default value, it is listed
in this column.
The Restrictions column summarizes the restrictions on
the parameter, such as acceptable ranges of values.
The Syntax column points to the SQL segment that gives the detailed
syntax for the parameter.
Using Examples
To understand the main syntax diagram and subdiagrams for a
statement, study the examples of syntax that appear in the rules of
usage for each statement. These examples have two purposes:
To show how to accomplish particular tasks with the statement or
its clauses
To show how to use the syntax of the statement or its clauses in a
concrete way
How to Enter SQL Com ments
Using Rela ted Information
For help in understanding the concepts and terminology in the
SQL
statement description, check the “Related Information” section at
the end of each statement.
This section points to related information in this manual and other
manuals that helps you to understand the statement in question. The
section provides some or all of the following information:
The names of related statements that might contain a fuller
discussion of topics in this statement
The titles of other manuals that provide extended discussions
of topics in this statement
Tip: If you do not have extensive knowledge and experience
with SQL,the“Informix Guide to SQL: Tutorial” gives you the
basic SQL knowledge that you need to under- stand and use the
statement descriptions in this manual.
How to Enter SQL Comments
You can add comments to clarify the purpose or effect of particular
SQL state- ments. You can also use comment symbols during program
development to disable selected statements without deleting them
from your source code.
Your comments can help you or others to understand the role of the
statement within a program, SPL routine, or command file. The
code examples in this manual sometimes include comments that
clarify the role of an SQL statement within the
code.
The following table shows the SQL comment symbols that you can
enter in your code. A Y in a column signifies that you
can use the symbol with the product or database type named in the
column heading. An N in a column signifies that you
cannot use the symbol with the product or database type that the
column heading names.
How to Enter SQL Comments
If the product that you are using supports both comment symbols,
your choice of a comment symbol depends on your requirements for
ANSI
compliance:
Braces ({}) are an Informix extension to the standard.
If ANSI compliance is not an issue, your choice of comment
symbols is a mat- ter of personal preference. ♦
In DB-Access, you can use either comment symbol when you enter SQL
state- ments with the SQL editor and when you create SQL command
files with the SQL editor or a system editor. An
SQL command file is an operating-system file that contains one
or moreSQL statements. Command files are also known as command
scripts. For more information about command files, see the
discussion of command scripts in the Informix Guide to SQL:
Tutorial. For information on how to create and modify command
files with the SQL editor or a system editor in DB-Access, see the
DB-Access User’s Manual. ♦
You can use either comment symbol in any line of an
SPL routine. See the discussion of how to comment and document
an SPL routine in the Informix Guide to SQL: Tutorial.
♦
Comment Symbol ESQL/C
SPL Routine DB-Access
ANSI- Compliant Databases
double dash (--)
Y Y Y Y Y The double dash precedes the comment. The double dash can
comment only a single line. To comment morethan one line, you must
put the double dash at the beginning of each comment
line.
braces ({})
N Y Y Y Y Braces enclose the comment. The { precedes the comment,
and the } follows the comment. You can use braces for
single-line comments or for multiple-line comments. Comments cannot
be nested.
How to Enter SQL Com ments
In ESQL/C, you can use the double dash (--) to comment SQL
statements. For further information on the use
of SQL comment symbols and language- specific comment
symbols in ESQL/C programs, see the Informix ESQL/C
Programmer’s Manual. ♦
Examples of SQL Comment Symbols
Some simple examples can help to illustrate the different ways to
use the SQL
comment symbols.
Example s of t he Double-Dash Symbol
The following example shows the use of the double dash (--) to
comment an SQL statement. In this example, the comment appears on
the same line as the statement.
SELECT * FROM customer -- Selects all columns and rows
In the following example, the user enters the same
SQL statement and the same comment as in the preceding
example, but the user places the comment on a line by itself:
SELECT * FROM customer -- Selects all columns and rows
In the following example, the user enters the same
SQL statement as in the preceding example but now enters a
multiple-line comment:
SELECT * FROM customer -- Selects all columns and rows -- from the
customer table
Examples of the Braces Symbols
The following example shows the use of braces ({}) to comment an
SQL
statement. In this example, the comment appears on the same line as
the statement.
SELECT * FROM customer {Selects all columns and rows}
Categories of SQL Statements
In the following example, the user enters the same
SQL statement and the same comment as in the preceding example
but places the comment on a line by itself:
SELECT * FROM customer {Selects all columns and rows}
In the following example, the user enters the same
SQL statement as in the preceding example but enters a
multiple-line comment:
SELECT * FROM customer {Selects all columns and rows from the
customer table}
Non-ASCII Characte rs in SQL Comment s
You can enter non-ASCII characters (including multibyte
characters) in SQL
comments if your locale supports a code set with the
non-ASCII characters. For further information on the GLS
aspects of SQL comments, see the Informix Guide to GLS
Functionality.
Cat egories of SQL Sta tements
SQL statements are divided into the following
categories:
Data definition statements
Data manipulation statements
Cursor manipulation statements
Cursor optimization statements
Dynamic management statements
Data access statements
Data integrity statements
Categories of SQL Statements
Cursor Manipulation Statements
ALTER FRAGMENT ALTER FUNCTION ALTER INDEX ALTER PROCEDURE ALTER
ROUTINE ALTER TABLE CLOSE DATABASE CREATE AGGREGATE CREATE CAST
CREATE DATABASE CREATE DISTINCT TYPE CREATE EXTERNAL TABLE CREATE
INDEX CREATE OPAQUE TYPE CREATE PROCEDURE CREATE PROCEDURE FROM
CREATE ROLE CREATE ROW TYPE CREATE SCHEMA CREATE SYNONYM CREATE
TABLE
CREATE TEMPORARY TABLE CREATE TRIGGER CREATE VIEW DATABASE DROP
AGGREGATE DROP CAST DROP DATABASE DROP INDEX DROP PROCEDURE DROP
ROLE DROP ROW TYPE DROP SYNONYM DROP TABLE DROP TRIGGER DROP VIEW
RENAME COLUMN RENAME DATABASE RENAME TABLE TRUNCATE
DELETE INSERT LOAD
SELECT UNLOAD UPDATE
Categories of SQL Statements
Data Access Statements
Data Integrity Statements
EXECUTE EXECUTE IMMEDIATE FREE GET DESCRIPTOR PREPARE SET
DEFERRED_PREPARE SET DESCRIPTOR
GRANT GRANT FRAGMENT LOCK TABLE REVOKE REVOKE FRAGMENT SET
ISOLATION
SET LOCK MODE SET ROLE SET SESSION AUTHORIZATION SET TRANSACTION
SET TRANSACTION MODE UNLOCK TABLE
BEGIN WORK COMMIT WORK ROLLBACK WORK SET DATABASE OBJECT MODE SET
LOG
SET PLOAD FILE SET TRANSACTION MODE START VIOLATIONS TABLE STOP
VIOLATIONS TABLE
SET EXPLAIN SET OPTIMIZATION SET PDQPRIORITY SET RESIDENCY
SET SCHEDULE LEVEL SET STATEMENT CACHE UPDATE STATISTICS
Categories of SQL Statements
Routine Definition Sta tements
Important: Optical Subsystemstatements are described in the
“Guide to the Optical Subsystem.”
ALTER FUNCTION ALTER PROCEDURE ALTER ROUTINE CREATE FUNCTION CREATE
FUNCTION FROM CREATE PROCEDURE CREATE PROCEDURE FROM
CREATE ROUTINE FROM DROP FUNCTION DROP PROCEDURE DROP ROUTINE
EXECUTE FUNCTION EXECUTE PROCEDURE SET DEBUG FILE TO
INFO OUTPUT GET DIAGNOSTICS
ANSI Compliance and Extensions
The following lists show statements that are compliant with the
ANSI SQL-92 standard at the entry level, statements that are
ANSI compliant but include Informix extensions, and statements
that are Informix extensions to the ANSI
standard.
CLOSE COMMIT WORK ROLLBACK WORK
SET SESSION AUTHORIZATION SET TRANSACTION
CREATE SCHEMA AUTHORIZATION CREATE TABLE CREATE TEMPORARY TABLE
CREATE VIEW DECLARE DELETE EXECUTE FETCH
GRANT INSERT OPEN SELECT SET CONNECTION UPDATE WHENEVER
ANSI Compl iance and Extensions
Sta tements That Are Extensions to t he ANSI Standard
ALLOCATE DESCRIPTOR ALTER FRAGMENT ALTER FUNCTION ALTER INDEX ALTER
OPTICAL CLUSTER ALTER PROCEDURE ALTER ROUTINE ALTER TABLE BEGIN
WORK CLOSE DATABASE CONNECT CREATE AGGREGATE CREATE DATABASE CREATE
EXTERNAL TABLE CREATE INDEX CREATE OPTICAL CLUSTER CREATE PROCEDURE
CREATE PROCEDURE FROM CREATE ROLE CREATE SYNONYM CREATE TRIGGER
DATABASE DEALLOCATE DESCRIPTOR DESCRIBE DISCONNECT DROP AGGREGATE
DROP DATABASE DROP INDEX DROP OPTICAL CLUSTER DROP PROCEDURE DROP
ROLE DROP SYNONYM DROP TABLE DROP TRIGGER DROP VIEW EXECUTE
IMMEDIATE EXECUTE PROCEDURE FLUSH FREE GET DESCRIPTOR GET
DIAGNOSTICS
ALLOCATE DESCRIPTOR. . . . . . . . . . . . . . . 2-8
ALLOCATE ROW . . . . . . . . . . . . . . . . . . 2-10
ALTER FRAGMENT . . . . . . . . . . . . . . . . . 2-12
ALTER FUNCTION . . . . . . . . . . . . . . . . . 2-41
ALTER INDEX . . . . . . . . . . . . . . . . . . . 2-44
ALTER PROCEDURE . . . . . . . . . . . . . . . . 2-48
ALTER ROUTINE . . . . . . . . . . . . . . . . . . 2-51
ALTER TABLE . . . . . . . . . . . . . . . . . . . 2-55
BEGIN WORK . . . . . . . . . . . . . . . . . . . 2-91
CREATE ROLE . . . . . . . . . . . . . . . . . . . 2-212
SET DATASKIP . . . . . . . . . . . . . . . . . . . 2-709
SET DEFERRED_PREPARE . . . . . . . . . . . . . . . 2-715
SET DESCRIPTOR . . . . . . . . . . . . . . . . . . 2-719
SET EXPLAIN . . . . . . . . . . . . . . . . . . . . 2-730
SET ISOLATION . . . . . . . . . . . . . . . . . . . 2-736
SET Residency . . . . . . . . . . . . . . . . . . . 2-756
SET ROLE. . . . . . . . . . . . . . . . . . . . . 2-758
In This Chapter
ALLOCATE COLLECTION
ALLOCATE COLLECTION
Use the ALLOCATE COLLECTION statement to allocate memory
for a collection variable.
Use this statement with ESQL/C.
Syntax
Usage
The ALLOCATE COLLECTION statement allocates memory for a variable
that stores collection data. To create a collection variable for an
ESQL/C program, perform the following steps:
1. Declare the collection variable as a client collection variable
in an ESQL/C program.
The collection variable can be a typed or untyped collection
variable.
2. Allocate memory for the collection variable with the
ALLOCATE
COLLECTION statement.
The ALLOCATE COLLECTION statement
sets SQLCODE (sqlca.sqlcode) to zero (0) if the memory
allocation was successful and to a negative error code if the
allocation failed.
You must explicitly release memory with the DEALLOCATE
COLLECTION
statement. Once you free the collection variable with the
DEALLOCATE
COLLECTION statement, you can reuse the collection variable.
+
Element Purpose Restrictions Syntax
variable Name that identifies a typed or untyped collection
variable for which to allocate memory
The variable must be the name of an unallocated ESQL/C collection
host variable.
Name must conform to language-specific rules for variable
names.
variable ALLOCATE COLLECTION
Tip: The ALLOCATE COLLECTION statement
allocates memory for an ESQL/C
collection variable only. To allocate memory for an ESQL/C row
variable, use the ALLOCATE ROW statement.
Examples
The following example shows how to allocate resources with the
ALLOCATE
COLLECTION statement for the untyped collection
variable, a_set:
EXEC SQL BEGIN DECLARE SECTION; client collection a_set;
EXEC SQL END DECLARE SECTION; . . .
EXEC SQL allocate collection :a_set; . . .
The following example uses ALLOCATE COLLECTION to allocate
resources for a typed collection variable, a_typed_set:
EXEC SQL BEGIN DECLARE SECTION; client collection set(integer not
null) a_typed_set;
EXEC SQL END DECLARE SECTION; . . . EXEC SQL allocate collection
:a_typed_set; . . .
Related Information
Related examples: Refer to the collection variable example in
PUT
Related statements: ALLOCATE ROW and DEALLOCATE COLLECTION
For a discussion of collection data types, see the Informix ESQL/C
Programmer’s Manual.
ALLOCATE DESCRIPTOR
ALLOCATE DESCRIPTOR
Use the ALLOCATE DESCRIPTOR statement to allocate memory
for a system- descriptor area. This statementcreates a place in
memory to hold information that a DESCRIBE statement obtains or to
hold information about the WHERE
clause of a statement.
Syntax
Use single quotes.
String must represent the name of an unallocated system- descriptor
area.
Quoted String, p. 4-260
descriptor_var Host-variable name that identifies a
system-descriptor area
Variable must contain the name of an unallocated system- descriptor
area.
Name must conform to language-specific rules for variable
names.
items Number of item descriptors in the system-descriptor
area
The default value is 100.
Value must be unsigned INTEGER greater than zero.
Literal Number, p. 4-237
Data type must be INTEGER or SMALLINT.
Name must conform to language-specific rules for variable
names.
descriptor_var WITH MAX
'descriptor ' ALLOCATE DESCRIPTOR
Usage
The ALLOCATE DESCRIPTOR statement creates a system-descriptor
area. A system-descriptor area contains one or more fields called
item descriptors. Each item descriptor holds a data value that the
database server can receive or send. The item descriptors also
contain information about the data such as type, length, scale,
precision, and nullability.
If the name that you assign to a system-descriptor area matches the
name of an existing system-descriptor area, the database
server returns an error. If you free the descriptor with the
DEALLOCATE DESCRIPTOR statement, you can reuse the
descriptor.
A system-descriptor area holds information that a DESCRIBE...USING
SQL
DESCRIPTOR statement obtains or it holds information about the
WHERE
clause of a dynamically executed statement.
WITH MAX Clause
You can use the WITH MAX clause to indicate the maximum number of
item descriptors you need. When you use this clause, the COUNT
field is set to the number of items you specify. If you do not
specify the WITH MAX clause, the default value of the
COUNT field is 100. You can change the value of the
COUNT field with the SET DESCRIPTOR statement.
The following examples show valid ALLOCATE DESCRIPTOR statements.
Each example includes the WITH MAX clause. The first line uses
embedded variable names to identify the system-descriptor area and
to specify the desired number of item descriptors. The second line
uses a quoted string to identify the system-descriptor area and an
unsigned integer to specify the desired number of item
descriptors.
EXEC SQL allocate descriptor :descname with max :occ;
EXEC SQL allocate descriptor 'desc1' with max 3;
Related Information
EXECUTE, FETCH, GET DESCRIPTOR, OPEN, PREPARE, PUT, and SET
DESCRIPTOR
For more information on system-descriptor areas, refer to the
Informix ESQL/C Programmer’s Manual.
ALLOCATE ROW
ALLOCATE ROW
Use the ALLOCATE ROW statement to allocate memory for a row
variable.
Use this statement with ESQL/C.
Syntax
Usage
The ALLOCATE ROW statement allocates memory for a variable that
stores row-type data. To create a row variable, perform the
following steps in your ESQL/C program:
1. Declare the row variable.
The row variable can be a typed or untyped row variable.
2. Allocate memory for the row variable with the ALLOCATE ROW
statement.
The ALLOCATE ROW statement
sets SQLCODE (sqlca.sqlcode) to zero (0) if the
memory allocation was successful and to a negative error code if
the allocation failed.
You must explicitly release memory with the DEALLOCATE ROW
statement. Once you free the row variable with the DEALLOCATE ROW
statement, you can reuse the row variable.
Tip: The ALLOCATE ROW statement allocates memory
for an ESQL/C row variable only. To allocate memory for an
ESQL/C collection variable, use the ALLOCATE
COLLECTION statement.
Element Purpose Restrictions Syntax
variable Name that identifies a typed or untyped row variable for
which to allocate memory
The variable must be an unallo- cated ESQL/C row host
variable.
Name must conform to language-specific rules for variable
names.
variable ALLOCATE ROW
ALLOCATE ROW
When you use the same row variable in multiple calls without
deallocating it, a memory leak on the client computer results.
Because there is no way to determine if a pointer is valid when it
is passed, ESQL/C assumes that it is not valid and assigns it to a
new memory location.
Example
The following example shows how to allocate resources with the
ALLOCATE
ROW statement for the typed row variable, a_row:
EXEC SQL BEGIN DECLARE SECTION; row (a int, b int) a_row;
EXEC SQL END DECLARE SECTION; . . . EXEC SQL allocate row
:a_row;
Related Information
Related statements: ALLOCATE COLLECTION and DEALLOCATE
ROW
For a discussion of complex types, see the Informix ESQL/C
Programmer’s Manual.
ALTER FRAGMENT
ALTER FRAGM ENT
Use the ALTER FRAGMENT statement to alter the distribution
strategy or storage location of an existing table or index.
Syntax
surviving_index Index on which you execute the ALTER FRAGMENT
statement
The index must exist at the time you execute the statement.
Database Object Name, p. 4-50
surviving_table Table on which you execute the ALTER FRAGMENT
statement
The table must exist at the time you execute the statement.
For more information, see “Restrictions on When You Can Use the
ALTER FRAGMENT Statement” on page 2-14.
Database Object Name, p. 4-50
INIT Clause p. 2-27
DETACH Clause p. 2-25
MODIFY Clause p. 2-38
ADD Clause p. 2-35
DROP Clause p. 2-37
Usage
The clauses of the ALTER FRAGMENT statement let you perform
the following tasks.
The ALTER FRAGMENT statement applies only to table or index
fragments that are located at the current site (or cluster, for
Extended Parallel Server). No remote information is accessed or
updated.
Warning: This statement can cause indexes to be dropped and
rebuilt. Before under- taking alter operations, check corresponding
sections in your “Performance Guide” to review effects and
strategies
General Privileges
You must have the Alter or the DBA privilege to change the
fragmentation strategy of a table. You must have the Index or the
DBA privilege to alter the fragmentation strategy of an
index.
Clause Purpose
ATTACH Combines tables thatcontainidentical table structures intoa
single fragmented table.
DETACH Detaches a table fragment or slice from a fragmentation
strategy and places it in a new table.
INIT Provides the following options:
Defines and initializes a fragmentation strategy on a table.
Creates a fragmentation strategy for tables.
Changes the order of evaluation of fragment expressions.
Alters the fragmentation strategy of an existing table or
index.
Changes the storage location of an existing table.
ADD Adds an additional fragment to an existing fragmentation
list.
DROP Drops an existing fragment from a fragmentation list.
MODIFY Changes an existing fragmentation expression.
ALTER FRAGMENT
Restrictions on When You Can Use the ALTER FRAGMENT
Statement
You cannot use the ALTER FRAGMENT statement on a temporary
table, an external table, or a view.
If your table or index is not already fragmented, the only clauses
available to you are INIT and ATTACH.
You cannot use ALTER FRAGMENT on a typed table that is part of
a table hierarchy. ♦
You cannot use the ALTER FRAGMENT statement on a
generalized-key (GK) index. Also, you cannot use the ALTER
FRAGMENT statement on any table that has a dependent GK index
defined on it. In addition, you cannot use this statement on a
table that has range fragmentation.
If the surviving_table has hash fragmentation, the only
clauses available are ATTACH and INIT. ♦
How Is the ALTER FRAGMENT Statement Executed?
If your database uses logging, the ALTER FRAGMENT statement is
executed within a single transaction. When the fragmentation
strategy uses large numbers of records, you might run out of log
space or disk space. (The database server requires extra disk space
for the operation; it later frees the disk space).
Making More Space
When you run out of log space or disk space, try one of the
following procedures to make more space available:
Turn off logging and turn it back on again at the end of the
operation. This procedure indirectly requires a backup of the root
dbspace.
Split the operations into multiple ALTER FRAGMENT statements,
moving a smaller portion of records at each time.
For information about log-space requirements and disk-space
requirements, see your Administrator’s Guide. That guide also
contains detailed instructions about how to turn off logging. For
information about backups, refer to your Backup and Restore
Guide.
Determining the Number of Rows in the Fragment
You can place as many rows into a fragment as the available space
in the dbspace allows.
To find out how many rows are in a fragment
1. Run the UPDATE STATISTICS statement on the table. This stepfills
the sysfragments system catalog table with the current table
information.
2. Query the sysfragments system catalog table to examine the
npused and nrows fields. The npused field gives
you the number of data pages used in the fragment, and
the nrows field gives you the number of rows in the
fragment.
ATTACH Clause
Use the ATTACH clause to combine tables that contain identical
table structures into a fragmentation strategy.
Important: Use the CREATE TABLE statement or the
INIT clause of the ALTER
FRAGMENT statement to create fragmented tables.
ATTACH Clause
ATTACH 1 surviving_table
ALTER FRAGMENT
Element Purpose Restrictions Syntax
consumed_table Table which loses its identity and becomes part of
the surviving table
The table must exist at the time you execute the statement.
The table cannot contain serial columns.
The table cannot contain unique, referential, or primary-key
constraints.
The table must be nonfrag- mented (IDS only).
See also, “General Restrictions for the ATTACH Clause” on page
2-17.
Database Object Name, p. 4-50
dbspace Dbspace that specifies where the consumed table expression
occurs in the fragmentation list
With a hybrid-fragmented table,dbspace identifiesa setof
dbspaces (XPS only). See “Altering Hybrid-Fragmented Tables” on
page 2-19.
The dbspace must exist at the time you execute the statement.
Identifier, p. 4-205
expression Expression that defines which rows are stored in a
fragment
The expression element can contain only columns from the current
table and only data values from a single row.
No subqueries, user-defined routines, aggregates, or refer- ences
to the fields of a row-type column are allowed. In addition, the
current, date and/or time built-in functions are not
allowed.
Condition, p. 4-27, and Expression, p. 4-73
surviving_table Table that survives the execution of ALTER
FRAGMENT
The table must exist at the time you execute the statement.
The table cannot contain any constraints.
See also, “General Restrictions for the ATTACH Clause” on page
2-17.
Database Object Name, p. 4-50
The ATTACH clause allows you to perform the following
tasks:
Create a single fragmented table by combining two or more identi-
cally-structured, nonfragmented tables
(See “Combining Nonfragmented Tables to Create a Fragmented Table”
on page 2-18.)
Attach one or more tables to a fragmented table
(See “Attaching a Table to a Fragmented Table” on page 2-19.)
Privileges
You must be the DBA or the owner of the tables that are
involved to use the ATTACH clause.
Genera l Restric tions for t he ATTACH Clause
Any tables that you attach must have been created previously in
separate dbspaces. You cannot attach the same table more than
once.
All consumed tables listed in the ATTACH clause must be
identical in structure to the surviving table; that is, all column
definitions must match. The number, names, data types, and relative
position of the columns must be identical.
You cannot attach a fragmented table to another fragmented
table. ♦
Additional Restrictions on the ATTACH Clause Specific to
XPS
In addition to the general restrictions, every consumed table must
be of the same usage type as the surviving table. For information
about how to specify the usage type of a table, refer to
“Usage-Type Options” on page 2-231.
You cannot use the ATTACH clause in certain situations. The attach
operation fails:
if the consumed tables contain data that belongs in some existing
fragment of the surviving table.
if existing data in the surviving table would belong in a new
fragment.
IDS
XPS
ALTER FRAGMENT
In other words, you cannot use the ATTACH clause for data
movement among fragments. To perform this task, see the “INIT
Clause” on page 2-27.
Using the BEFORE, AFTER, and REM AINDER Options
The BEFORE and AFTER options allow you to place a new
fragment either before or after an existing dbspace. You
cannot use the BEFORE and AFTER
options when the distribution scheme is round-robin.
When you attach a new fragment without an explicit BEFORE or
AFTER
option, the database server places the added fragment at the end of
the fragmentation list, unless a remainder fragment exists. If a
remainder fragment exists, the new fragment is placed just before
the remainder fragment. You cannot attach a new fragment after the
remainder fragment.
When you create or append to a hybrid-fragmented table, the
positioning specification (BEFORE, AFTER, or REMAINDER)
applies to an entire dbslice. You can use any dbspace in a dbslice
to identify the dbslice for the BEFORE or AFTER position.
♦
Combining Nonfragmented Tables to Create a Fragmented
Table
When you transform tables with identical table structures into
fragments in a single table, you allow the database server to
manage the fragmentation instead of allowing the application to
manage the fragmentation. The distri- bution scheme can be
round-robin or expression-based.
To make a single, fragmented table from two or more
identically-structured, nonfragmented tables, the
ATTACH clause must contain the surviving table in the attach
list. The attach list is the list of tables in the
ATTACH clause.
To include a rowid column in the newly-created single,
fragmented table, attach all tables first and then add
the rowid with the ALTER TABLE
statement. ♦
XPS
IDS
Attaching a Table to a Fragmented Table
To attach a nonfragmented table to an already fragmented table, the
nonfragmented table must have been created in a separate dbspace
and must have the same table structure as the fragmented table. In
the following example, a round-robin distribution scheme fragments
the table cur_acct, and the table old_acct is a
nonfragmented table that resides in a separate dbspace. The example
shows how to attach old_acct to cur_acct:
ALTER FRAGMENT ON TABLE cur_acct ATTACH old_acct
When you attach one or more tables to a fragmented table, a
consumed table must be nonfragmented. ♦
When you attach one or more tables to a fragmented table, a
consumed table can be nonfragmented or have hash
fragmentation.
If you specify a consumed_table that has hash fragmentation, the
hash column specification must match that of the surviving_table
and any other consumed_table involved in the attach operation.
♦
Altering Hybrid-Fragmented Tables
When you alter a hybrid-fragmented table with either an
ATTACH or DETACH clause, you need specify only one dbspace to
identify the entire set of dbspaces that are associated with a
given expression in the base fragmen- tation strategy of the
table.
The set of dbspaces associated with an expression in the base
fragmentation strategy of the table might have been defined as one
or more dbslices or a dbspaces. For more information, see
“Fragmenting by HYBRID” on page 2-264.
If you know the name of the dbslice, but not any of the dbspaces
that it comprises, you can name the first dbspace in the dbslice by
adding .1 to the name of the dbslice. For example, if the dbslice
were named dbsl1, you could specify dbsl1.1.
IDS
XPS
XPS
ALTER FRAGMENT
What Happens?
After the attach executes, all consumed tables no longer exist. Any
constraints (CHECK or NOT NULL) that were on the consumed tables
also no longer exist.
You must reference the records that were in the consumed tables
through the surviving table.
What Happens to Indexes?
In a logging database, when the attach executes, the database
server extends any attached index on the surviving table according
to the new fragmen- tation strategy of the surviving table. All
rows in the consumed table are subject to these automatically
adjusted indexes. For information on whether the database server
completely rebuilds the index on the surviving table or reuses an
index that was on the consumed table, see your Performance
Guide.
In a nonlogging database, when the attach executes, the database
server does not extend indexes on the surviving table according to
the new fragmen- tation strategy of the surviving table. To extend
the fragmentation strategy of an attached index according to
the new fragmentations strategy of the surviving table, you must
drop the index and recreate it on the surviving table.
♦
A detached index on the surviving table retains its same
fragmentation strategy. That is, a detached index does not
automatically adjust to accom- modate the new fragmentation of the
surviving table.
For more information on what happens to indexes, see the discussion
about altering table fragments in your Performance Guide.
What Happens to BYTE and TEXT Columns?
Each BYTE and TEXT column in every table that is named in
the ATTACH
clause must have the same storage type, either blobspace or
tblspace. If the BYTE or TEXT column is stored in a
blobspace, the same column in all tables must be in the same
blobspace. If the BYTE or TEXT column is stored in a
tblspace, the same column must be stored in a tblspace in all
tables. ♦
ALTER FRAGMENT
In Extended Parallel Server, BYTE and TEXT columns are
stored in separate fragments that are created for that purpose. If
a table includes a BYTE or TEXT
column, the database server creates a separate, additional fragment
in the same dbspace as each regular table fragment. BYTE or
TEXT columns are stored in the separate fragment that is
associated with the regular table fragment where a given row
resides.
When an attach occurs, BYTE and TEXT fragments of the
consumed table become part of the surviving table and
continue to be associated with the same rows and data fragments as
they were before the attach. ♦
What Happens to Triggers?
When you attach tables, any triggers that are defined on the
consumed table no longer exist, and all rows in the consumed table
are subject to the triggers that are defined in the surviving
table. That is, triggers on the surviving table survive the
ATTACH, but triggers on the consumed table are dropped.
No triggers are activated with the ATTACH clause, but
subsequent data- manipulation operations on the new rows can
activate triggers.
What Happens to Views?
Views on the surviving table survive the ATTACH, but views on
the consumed table are dropped.
What Happens with the Distribution Scheme?
You can attach a nonfragmented table to a table with any type of
supported distribution scheme. In general, the resulting table has
the same fragmen- tation strategy as the prior fragmentation
strategy of the surviving_table. However, when you attach two or
more nonfragmented tables, the distri- bution scheme can
either be based on expression or round-robin.
XPS
ALTER FRAGMENT
♦
The following table shows the distribution schemes that can result
from different distribution schemes of the tables mentioned in the
ATTACH clause.
When you attach a nonfragmented table to a table that has hash
fragmen- tation, the resulting table has hybrid
fragmentation.
You can attach a table with a hash distribution scheme to a table
that currently has no fragmentation, hash fragmentation, or hybrid
fragmen- tation. In any of these situations, the resulting table
has a hybrid distribution scheme. ♦
Prior Distribution Scheme of Surviving Table
Prior Distribution Scheme of Consumed Table Result ing Distr ibut
ion Scheme
None None Round-robin or expression
Round-robin None Round-robin
Expression None Expression
Prior Distribution Scheme of Surviving Table
Prior Distribution Scheme of Consumed Table Result ing Distr ibut
ion Scheme
None None Round-robin or expression
None Hash Hybrid
Round-robin None Round-robin
Expression None Expression
Hash None Hybrid
Hash Hash Hybrid
Hybrid None Hybrid
Hybrid Hash Hybrid
Examples
The following examples illustrate the use of the ATTACH clause to
create fragmented tables with different distribution schemes.
Round-Robin Distribution Scheme
The following example combines nonfragmented
tables pen_types and pen_makers into a single,
fragmented table, pen_types. Table pen_types resides in
dbspace dbsp1, and table pen_makers resides in
dbspace dbsp2. Table structures are identical in each
table.
ALTER FRAGMENT ON TABLE pen_types ATTACH pen_types,
pen_makers
After you execute theATTACH clause, thedatabase server fragments
the table pen_types round-robin into two dbspaces: the dbspace
that contained pen_types and the dbspace that
contained pen_makers. Table pen_makers is consumed, and
no longer exists; all rows that were in table pen_makers are now in
table pen_types.
Expression Distribution Scheme
Consider the following example that combines tables cur_acct and
new_acct and uses an expression-based distribution scheme.
Table cur_acct was origi- nally created as a fragmented
table and has fragments in dbspaces dbsp1 and dbsp2. The first
statement of the example shows that table cur_acct was
created with an expression-based distribution scheme. The second
statement of the example creates
table new_acct in dbsp3 without a fragmentation
strategy. The third statement combines the
tables cur_acct and new_acct. Table structures
(columns) are identical in each table.
CREATE TABLE cur_acct (a int) FRAGMENT BY EXPRESSION a < 5 in
dbsp1, a >= 5 and a < 10 in dbsp2;
CREATE TABLE new_acct (a int) IN dbsp3;
ALTER FRAGMENT ON TABLE cur_acct ATTACH new_acct AS a>=10;
When you examine the sysfragments system catalog table after you
alter the fragment, you see that table cur_acct is fragmented
by expression into three dbspaces. For additional information about
the sysfragments system catalog table, see the Informix Guide to
SQL: Reference.
ALTER FRAGMENT
In addition to simple range rules, you can use the ATTACH clause to
fragment by expression with hash or arbitrary rules. For a
discussion of all types of expressions in an expression-based
distribution scheme, see “FRAGMENT BY Clause for Tables” on page
2-30.
Warning: When you specify a date value in a fragment
expression, make sure to specify 4 digits instead of 2 digits for
the year. When you specify a 4-digit year, the
DBCENTURY environment variable has no effect on the
distribution scheme. When you specify a 2-digit year, the
DBCENTURY environment variable can affect the
distribution scheme and can produce unpredictable results. For more
information on the DBCENTURY environment variable, see the
“Informix Guide to SQL: Reference.”
Hybrid Fragmentation Distribution Scheme
Consider a case where monthly sales data is added to
the sales_info table defined below. Due to the large
amount of data, the table is distributed evenly across multiple
coservers with a system-defined hash function. To manage monthly
additions of data to the table, it is also fragmented by a date
expression. The combined hybrid fragmentation is declared in the
following CREATE TABLE statement:
CREATE TABLE sales_info (order_num int, sale_date date, ...)
FRAGMENT BY HYBRID (order_num) EXPRESSION sale_date >=
'01/01/1996' AND sale_date < '02/01/1996' IN sales_slice_9601,
sale_date >= '02/01/1996' AND sale_date < '03/01/1996' IN
sales_slice_9602, . . . sale_date >= '12/01/1996' AND sale_date
< '01/01/1997' IN sales_slice_9612
The data for a new month is originally loaded from an external
source. The data is distributed evenly across the name coservers on
which the sales_info table is defined, using a system-defined hash
function on the same column:
CREATE TABLE jan_97 (order_num int, sale_date date, ...) FRAGMENT
BY HASH (order_num) IN sales_slice_9701
INSERT INTO jan_97 SELECT (...) FROM ...
Once the data is loaded, you can attach the new table
to sales_info. You can issue the following ALTER
FRAGMENT statement to attach the new table:
ALTER FRAGMENT ON TABLE sales_info ATTACH jan_97 AS sale_date >=
'01/01/1997' AND sale_date < '02/01/1997'
ALTER FRAGMENT
DETACH Clause
Use the DETACH clause to detach a table fragment from a
distribution scheme and place the contents into a new nonfragmented
table.
In Extended Parallel Server, the new table can also be a table with
hash fragmentation. ♦
For an explanation of distribution schemes, see “FRAGMENT BY Clause
for Tables” on page 2-30.
The new table that results from the execution of the DETACH clause
does not inherit any indexes or constraints from the original
table. Only the data remains.
The new table that results from the execution of the DETACH clause
does not inherit any privileges from the original table. Instead
this table has the default privileges for any new table. For
further information on default table- level privileges, see the
GRANT statement on “Table-Level Privileges” on page
2-505.
XPS
dbspace Dbspace that contains the fragment to be detached
With a hybrid-fragmented table, dbspace identifies a set of
dbspaces (XPS only). See “Altering Hybrid-Fragmented Tables” on
page 2-19.
The dbspace must exist when you execute the statement.
Identifier, p. 4-205
new_table Nonfragmented table that results after you execute the
ALTER FRAGMENT statement
In XPS, the table can also be a hash-fragmented table.
The table must not exist before you execute the statement.
Database Object Name, p. 4-50
DETACH Clause
dbspace new_table DETACH
ALTER FRAGMENT
Restrictions
The DETACH clause cannot be applied to a table if that table
is the parent of a referential constraint or if a rowid
column is defined on the table.
In Extended Parallel Server, you cannot use the DETACH clause
if the table has a dependent GK index defined on
it. ♦
Detach That Results in a Non-fragmented Table
The following example shows the table cur_acct fragmented
into two dbspaces, dbsp1 and dbsp2:
ALTER FRAGMENT ON TABLE cur_acct DETACH dbsp2 accounts
This example detaches dbsp2 from the distribution scheme
for cur_acct and places the rows in a new
table, accounts. Table accounts now has the same
structure (column names, number of columns, data types, and so on)
as table cur_acct, but the table accounts does not
contain any indexes or constraints from the table cur_acct.
Both tables are now nonfragmented.
The following example shows a table that contains three
fragments:
ALTER FRAGMENT ON TABLE bus_acct DETACH dbsp3 cli_acct
This statement detaches dbsp3 from the distribution
scheme for bus_acct and places the rows in a new
table, cli_acct. Table cli_acct now has the same
structure (column names, number of columns, data types, and so on)
as bus_acct, but the table cli_acct does not contain any
indexes or constraints from the table bus_acct.
Table cli_acct is a nonfragmented table, and table
bus_acct remains a fragmented table.
Detach That Results in a Table with Hash Fragmentat ion
The new table will be a hash-fragmented table if the
surviving_table had hybrid fragmentation and the detached
dbslice has more than one fragment. In a hybrid-fragmented table,
you specify the dbslice to be detached by naming any dbspace
in that slice.
XPS
XPS
ALTER FRAGMENT
Consider the sales_info table discussed in the “Hybrid
Fragmentation Distri- bution Scheme” on page 2-24. Once the
January 1997 data is available in the sales_info table, you
might archive year-old sales_info data.
ALTER FRAGMENT ON TABLE sales_info DETACH sales_slice_9601.1
jan_96
In this example, data from January 1996 is detached from the
sales_info table and placed in a new table
called jan_96.
INIT Clause
move a nonfragmented table from one dbspace to another
dbspace.
convert a fragmented table to a nonfragmented table.
fragment an existing table that is not fragmented without
redefining the table.
convert an existing fragmentation strategy to another fragmentation
strategy
fragment an existing index that is not fragmented without
redefining the index
convert a fragmented index to a nonfragmented index. ♦
Warning: When you execute the ALTER
FRAGMENT statement with this clause, it results in data
movement if the table contains any data. If data moves, the
potential exits for signi cant logging, for the transaction being
aborted as a long transaction, and for a relatively long exclusive
lock being held on the affected tables. Use this statement when it
does not interfere with day-to-day operations.
IDS
ALTER FRAGMENT
.
You cannot use the INIT clause to change the fragmentation strategy
of a table that has a GK index. ♦
For more information about thestorage spaces in which you can store
a table, see “Using the IN Clause” on page 2-257.
When you use the INIT clause to modify a table,
the tabid value in system catalog tables changes for the
affected table. The constrid of all unique and
referential constraints on the table also change.
Element Purpose Restrictions Syntax
dbslice Dbslice that contains the fragmented information
The dbslice must exist at the time you execute the statement.
Identifier, p. 4-205
dbspace Dbspace that contains the fragmented information
The dbspace must exist at the time you execute the statement.
Identifier, p. 4-205
INIT Clause
p. 2-30 WITH ROWIDS
XPS
Nonfragmented tables contain a pseudocolumn called
the rowid column. Fragmented tables do not contain this
column unless it is explicitly created.
Use the WITH ROWIDS option to add a new column called the rowid
column. The database server assigns a unique number to each row
that remains stable for the existence of the row. The database
server creates an index that it uses to find the physical location
of the row. Each row contains an additional 4 bytes to store
the rowid column after you add the WITH
ROWIDS option.
Important: Informix recommends that you use primary keys,
rather than the row id
column, as an access method.
Converting a Fragmented Table to a Nonfragmented Table
You might decide that you no longer want a table to be fragmented.
You can use the INIT clause to convert a fragmented table to a
nonfragmented table. Thefollowingexample shows the original
fragmentation definitionas well as how to use the ALTER
FRAGMENT statement to convert the table:
CREATE TABLE checks (col1 int, col2 int) FRAGMENT BY ROUND ROBIN IN
dbsp1, dbsp2, dbsp3;
ALTER FRAGMENT ON TABLE checks INIT IN dbsp1;
You must use the IN dbspace clause to place the table in a
dbspace explicitly.
When you use the INIT clause to change a fragmented table to a
nonfragmented table (that is, to rid the table of any fragmentation
strategy), all attached indexes become nonfragmented indexes. In
addition, constraints that do not use existing user indexes
(detached indexes) become nonfrag- mented indexes. All newly
nonfragmented indexes exist in the same dbspace as the new
nonfragmented table.
When you use the INIT clause to change a fragmented table to a
nonfragmented table, the fragmentation strategy of detached indexes
(and constraints that use detached indexes) is not affected.
IDS
ALTER FRAGMENT
FRAGM ENT BY Clause for Tables
Use the FRAGMENT BY portion of the INIT clause to fragment an
existing non- fragmented table or convert an existing fragmentation
strategy to another fragmentation strategy.
Back to INIT Clause p. 2-27
FRAGMENT BY ROUND ROBIN IN dbspace ,
dbspace
,
IN dbspace
ALTER FRAGMENT
For more information on the available fragmentation strategies, see
the “FRAGMENT BY Clause” on page 2-259.
Element Purpose Restrictions Syntax
column Name of the column or columns on which you want to apply the
fragmentation strategy
In the HYBRID clause, column identifies the column or columns on
which you want to apply the hash portion of the hybrid table
fragmentation strategy
The column must exist. Identifier, p. 4-205
dbslice Dbslice that contains the table fragment
The dbslice must be defined. Identifier, p. 4-205
dbspace Dbspace that contains the table fragment
You must specify at least two dbspaces. You can specify a maximum
of 2,048 dbspaces.
Identifier, p. 4-205
expression Expression that defines a table fragment using a range,
hash, or arbitrary rule
Each fragment expression can contain only columns from the current
table and only data values from a single row.
No subqueries, user-defined routines, aggregates, or refer- ences
to the fields of a row-type column are allowed. In addition, the
current, date and/or time built-in functions are not allowed.
Condition, p. 4-27, and Expression, p. 4-73
ALTER FRAGMENT
Changing an Existing Fragmentation Strategy on a Table
You can redefine a fragmentation strategy on a table if you decide
that your initial strategy does not fulfill your needs. When you
alter a fragmentation strategy, the database server discards the
existing fragmentation strategy and moves records to fragments as
defined in the new fragmentation strategy.
The following example shows the statement that originally defined
the fragmentation strategy on the table account and then
shows an ALTER
FRAGMENT statement that redefines the fragmentation
strategy:
CREATE TABLE account (col1 int, col2 int) FRAGMENT BY ROUND ROBIN
IN dbsp1, dbsp2;
ALTER FRAGMENT ON TABLE account INIT FRAGMENT BY EXPRESSION col1
< 0 in dbsp1, col2 >= 0in dbsp2;
If an existing dbspace is full when you redefine a fragmentation
strategy, you must not use it in the new fragmentation
strategy.
Defining a Fragmentation Strategy on a Nonfragmented
Table
You can use the INIT clause to define a fragmentation strategy
on a nonfragmented table. It does not matter whether the table was
created with a storage option.
When you use the INIT clause to fragment an existing nonfragmented
table, all indexes on the table become fragmented in the same way
as the table. ♦
When you use the INIT clause to fragment an existing nonfragmented
table, indexes retain their existing fragmentation strategy.
The following example shows the original table definition as well
as how to use the ALTER FRAGMENT statement to fragment the
table:
CREATE TABLE balances (col1 int, col2 int) IN dbsp1;
♦
FRAGM ENT BY Clause for Indexes
The INIT FRAGMENT BY clause for indexes allowsyou to fragment an
existing index that is not fragmented without redefining the index.
You can convert an existing fragmentation strategy to another
fragmentation strategy. Any existing fragmentation strategy is
discarded and records are moved to fragments as defined in the new
fragmentation strategy. You can also convert a fragmented index to
a nonfragmented index.
Use the FRAGMENT BY clause for indexes to define the
expression-based distribution scheme.
IDS
dbspace Dbspace that contains the fragmented information
You must specify at least two dbspaces. You can specify a maximum
of 2,048 dbspaces.
Identifier, p. 4-205
expression Expression that definesan index fragment byusing a
range,hash, or arbitrary rule
Each fragment expression can contain only columns from the current
table and only data values from a single row.
No subqueries, user-defined routines, aggregates, or references to
the fields of a row-type column are allowed. In addition, the
current, date and/or time built-in functions are not allowed.
Condition, p. 4-27, and Expression, p. 4-73
, REMAINDER IN dbspace
FRAGMENT BY Clause for Indexes
FRAGMENT BY EXPRESSION , expr ession
IN dbspace
,
ALTER FRAGMENT
Fragmenting Unique and System Indexes
You can fragment unique indexes only if the table uses an
expression-based distribution scheme. The columns that are
referenced in the fragment expression must be indexed columns. If
your ALTER FRAGMENT INIT
statement fails to meet either of these restrictions, the INIT
fails, and work is rolled back.
You might have an attached unique index on a table fragmented by
Column A. If you use INIT to change the table fragmentation
to Column B, the INIT fails because the unique index is
defined on Column A. To resolve this issue, you can use the
INIT clause on the index to detach it from the table fragmentation
strategy and fragment it separately.
System indexes (such as those used in referential constraints and
unique constraints) use user indexes if the indexes exist. If no
user indexes can be used, system indexes remain nonfragmented and
are moved to the dbspace where the database was created. To
fragment a system index, create the fragmented index on the
constraint columns, and then use the ALTER TABLE
statement to add the constraint.
Detaching an Index from a Table-Fragmentation Strategy
You can detach an index from a table-fragmentation strategy with
the INIT
ALTER FRAGMENT
ADD Clause
Use the ADD clause to add another fragment to an existing
fragmentation list.
IDS
existing_dbspace Name of a dbspace in an existing fragmentation
list
The dbspace must exist at the time you execute the statement.
Identifier, p. 4-205
expression Expression that defines the added fragment
The expression can contain only columns from the current table and
only data values from a single row.
No subqueries, user-defined routines, aggregates, or refer- ences
to the fields of a row-type column are allowed. In addition, the
current, date and/or time built-in functions are not allowed.
Condition, p. 4-27, and Expression, p. 4-73
new_dbspace Name of dbspace to be added to the fragmentation
scheme
The dbspace must exist at the time you execute the statement.
Identifier, p. 4-205
ADD Clause
ALTER FRAGMENT
Adding a New Dbspace to a Round-Robin Distribution
Scheme
You can add more dbspaces to a round-robin distribution scheme. The
following example shows the original round-robin definition:
CREATE TABLE book (col1 int, col2 title) FRAGMENT BY ROUND ROBIN in
dbsp1, dbsp4;
To add another dbspace, use the ADD clause, as shown in the
following example:
ALTER FRAGMENT ON TABLE book ADD dbsp3;
Adding