|
SQLite Requirements
1.0 Introduction
These requirements strive to describe the interfaces and operation of SQLite in sufficient detail that a compatible implementation of SQLite can be written solely from these requirements and without reference to the canonical SQLite source code.
Software development processes typically recognize a hierarchy of requirements:
- System requirements
- High-level requirements
- Derived high-level requirements
- Low-level requirements
- Derived low-level requirements
The usual distinction between high-level and low-level requirements is that high-level requirements describe "what" the system does and the low-level requirements describe "how" the system does it. Since the the requirements denoted here describe the behavior of SQLite and not its implementation, they are best thought of as high-level requirements. Consistent with that view, most of the requirements numbers begin with the letter "H" (for "high-level"). A few of the requirements presented here specify broad objectives that SQLite strives to achieve. These broad requirements can be thought of as system requirements and are number with an initial letter "S".
These requirements are hierarchical in the sense that the more specific requirements are derived from broader and more general requirements. When requirement B is derived from requirement A, we say that A is the parent of B and that B is a child of A. The parent/child relationships of all requirements are tracked. All requirements presented here ultimately derive from a single very broad, very high-level, and very general system requirement called "S10000".
Some behaviors of SQLite are undefined. For example, the order in which result rows are returned from a SELECT statement is undefined if there is no ORDER BY clause. As another example, many of the C interfaces require a pointer to an open database connection as their first argument and the behavior of those interfaces is undefined (and probably undesirable) if a pointer to some other object is supplied instead. Some, but not all undefined behaviors are explicitly stated and number in this document with numbers beginning with the "U" for "Undefined". Applications that use SQLite should never depend on undefined behavior. If a behavior is not explicitly defined by a requirement, then the behavior is undefined, and so explicitly stating undefined behaviors in this document is technically redundant. Nevertheless, we find that explicitly stating some undefined behaviors helps application developers to better understand the boundaries of operation of SQLite and to generate safer and more accurate programs that use SQLite.
2.0 System Requirements
3.0 Application C-Language Interfaces
4.0 C-Language Interfaces For Extending SQLite
5.0 Database File Format
6.0 SQL Language Specification
*** DRAFT ***