Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Identify requirements in the autoinc.html and datatype3.html documents. Make corrections in datatype3.html for accuracy and for clearer presentation. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
e18ce3ebd0591a83762898decce0920a |
User & Date: | drh 2009-12-14 23:00:10.000 |
Context
2009-12-15
| ||
00:29 | Add requirements markings to the pragma documentation. (check-in: a900d49554 user: drh tags: trunk) | |
2009-12-14
| ||
23:00 | Identify requirements in the autoinc.html and datatype3.html documents. Make corrections in datatype3.html for accuracy and for clearer presentation. (check-in: e18ce3ebd0 user: drh tags: trunk) | |
17:41 | For the requirements matrix, scan evidence marks in the original source code, not in the amalgamation. Updates to SQL comment documentation. (check-in: dca51f132e user: drh tags: trunk) | |
Changes
Changes to pages/autoinc.in.
1 2 3 4 5 | <title>SQLite Autoincrement</title> <h1>SQLite Autoincrement</h1> <tcl>hd_keywords AUTOINCREMENT</tcl> <p> | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 | <title>SQLite Autoincrement</title> <h1>SQLite Autoincrement</h1> <tcl>hd_keywords AUTOINCREMENT</tcl> <p> ^In SQLite, every row of every table has an 64-bit signed integer [ROWID]. ^The ROWID for each row is unique among all rows in the same table. </p> <p> ^(You can access the ROWID of an SQLite table using one the special column names ROWID, _ROWID_, or OID. Except if you declare an ordinary table column to use one of those special names, then the use of that name will refer to the declared column not to the internal ROWID.)^ </p> <p> ^If a table contains a column of type [INTEGER PRIMARY KEY], then that column becomes an alias for the ROWID. ^You can then access the ROWID using any of four different names, the original three names described above or the name given to the [INTEGER PRIMARY KEY] column. ^All these names are aliases for one another and work equally well in any context. </p> <p> ^When a new row is inserted into an SQLite table, the ROWID can either be specified as part of the INSERT statement or it can be assigned automatically by the database engine. ^(To specify a ROWID manually, just include it in the list of values to be inserted. For example: </p> <blockquote><pre> CREATE TABLE test1(a INT, b TEXT); INSERT INTO test1(rowid, a, b) VALUES(123, 5, 'hello'); </pre></blockquote>)^ <p> ^If no ROWID is specified on the insert, an appropriate ROWID is created automatically. ^The usual algorithm is to give the newly created row a ROWID that is one larger than the largest ROWID in the table prior to the insert. ^If the table is initially empty, then a ROWID of 1 is used. ^If the largest ROWID is equal to the largest possible integer (9223372036854775807) then the database engine starts picking candidate ROWIDs at random until it finds one that is not previously used. </p> <p> ^The normal ROWID selection algorithm described above will generate monotonically increasing unique ROWIDs as long as you never use the maximum ROWID value and you never delete the entry in the table with the largest ROWID. ^If you ever delete rows or if you ever create a row with the maximum possible ROWID, then ROWIDs from previously deleted rows might be reused when creating new rows and newly created ROWIDs might not be in strictly accending order. </p> <h2>The AUTOINCREMENT Keyword</h2> <p> ^If a column has the type INTEGER PRIMARY KEY AUTOINCREMENT then a slightly different ROWID selection algorithm is used. ^The ROWID chosen for the new row is at least one larger than the largest ROWID that has ever before existed in that same table. ^If the table has never before contained any data, then a ROWID of 1 is used. ^If the table has previously held a row with the largest possible ROWID, then new INSERTs are not allowed and any attempt to insert a new row will fail with an SQLITE_FULL error. </p> <p> ^SQLite keeps track of the largest ROWID that a table has ever held using the special SQLITE_SEQUENCE table. ^The SQLITE_SEQUENCE table is created and initialized automatically whenever a normal table that contains an AUTOINCREMENT column is created. ^The content of the SQLITE_SEQUENCE table can be modified using ordinary UPDATE, INSERT, and DELETE statements. ^But making modifications to this table will likely perturb the AUTOINCREMENT key generation algorithm. Make sure you know what you are doing before you undertake such changes. </p> <p> The behavior implemented by the AUTOINCREMENT keyword is subtly different from the default behavior. ^With AUTOINCREMENT, rows with automatically selected ROWIDs are guaranteed to have ROWIDs that have never been used before by the same table in the same database. ^And the automatically generated ROWIDs are guaranteed to be monotonically increasing. These are important properties in certain applications. But if your application does not need these properties, you should probably stay with the default behavior since the use of AUTOINCREMENT requires additional work to be done as each row is inserted and thus causes INSERTs to run a little slower. </p> <p>^Note that "monotonically increasing" does not imply that the ROWID always increases by exactly one. ^One is the usual increment. ^However, if an insert fails due to (for example) a uniqueness constraint, the ROWID of the failed insertion attempt might not be reused on subsequent inserts, resulting in gaps in the ROWID sequence. ^AUTOINCREMENT guarantees that automatically chosen ROWIDs will be increasing but not that they will be sequential.</p> |
Changes to pages/datatype3.in.
1 2 3 | <title>Datatypes In SQLite Version 3</title> <tcl>hd_keywords {datatype} {dynamic typing}</tcl> | | | | | | | | | | | | > | > | | > | | > | | > | | | > > > > > > > | > | > | > | | | | | < | > | | | | > | > < < | | > > > > > | | < > > | | < | < < < < < < < < < < < < < < < < | | | | | | | | | | | | | | | | | | | > | > | | | | > > | | | | > > | | | | | | | > | | | | | | | | | | | | | | | | > | | | | | < | < | | | | | | | | | | | | < | | | | < | | | | | | | > | > | | | | | < < < < < < | < | < < < < < < < < | < | | | < < | < > | | | < | | | | | | | | | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 | <title>Datatypes In SQLite Version 3</title> <tcl>hd_keywords {datatype} {dynamic typing}</tcl> <h1 align=center>Datatypes In SQLite Version 3</h1> <p>Most SQL database engines (every SQL database engine other than SQLite, as far as we know) uses static, rigid typing. With static typing, the datatype of a value is determined by its container - the particular column in which the value is stored.</p> <p>SQLite uses a more general dynamic type system. In SQLite, the datatype of a value is associated with the value itself, not with its container. The dynamic type system of SQLite is backwards compatible with the more common static type systems of other database engines in the sense that SQL statement that work on statically typed databases should would the same way in SQLite. However, the dynamic typing in SQLite allowed it to do things which are not possible in traditional rigidly typed databases.</p> <h2>1.0 Storage Classes</h2> <p>Each value stored in an SQLite database (or manipulated by the database engine) has one of the following storage classes:</p> <ul> <li><p><B>NULL</B>. The value is a NULL value.</p> <li><p><B>INTEGER</B>. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes depending on the magnitude of the value.</p> <li><p><B>REAL</B>. The value is a floating point value, stored as an 8-byte IEEE floating point number.</p> <li><p><B>TEXT</B>. The value is a text string, stored using the database encoding (UTF-8, UTF-16BE or UTF-16-LE).</p> <li><p><B>BLOB</B>. The value is a blob of data, stored exactly as it was input.</p> </ul> <p>Note that a storage class is slightly more general than a datatype. The INTEGER storage class, for example, includes 6 different integer datatypes of different lengths. This makes a different on-disk. But as soon as INTEGER values are read off of disk and into memory for processing, they are converted to the most general datatype (8-byte signed integer). And so for the most part, "storage class" is indistinguishable from "datatype" and the two terms can be used interchangably.</p> <p>^Any column in an SQLite version 3 database, except an [INTEGER PRIMARY KEY] column, may be used to store a value of any storage class.</p> <p>All values in SQL statements, whether as literals embedded in SQL statement text or [parameters] bound to [prepared statements | pre-compiled SQL statements] have an implicit storage class. Under circumstances described below, the database engine may convert values between numeric storage classes (INTEGER and REAL) and TEXT during query execution. </p> <h3>1.1 Boolean Datatype</h3> <p>SQLite does not have a separate Boolean storage class. ^Instead, Boolean values are stored as integers 0 (false) and 1 (true).</p> <h3>1.2 Date and Time Datatype</h3> <p>SQLite does not have any storage class set aside for storing dates and/or times. ^(Instead, the built-in [Date And Time Functions] of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:)^</p> <ul> <li><b>TEXT</b> as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS"). <li><b>REAL</b> as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar. <li><b>INTEGER</b> as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC. </ul> <p>Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.</p> <tcl>hd_fragment affinity affinity</tcl> <h2>2.0 Column Affinity</h2> <p> In order to maximize compatibility between SQLite and other database engines, SQLite supports the concept of "type affinity" on columns. The type affinity of a column is the recommended type for data stored in that column. The key here is that the type is recommended, not required. Any column can still store any type of data, in theory. It is just that some columns, given the choice, will prefer to use one storage class over another. The preferred storage class for a column is called its "affinity". </p> <p>^(Each column in an SQLite 3 database is assigned one of the following type affinities:</p> <ul> <li>TEXT</LI> <li>NUMERIC</LI> <li>INTEGER</LI> <li>REAL</li> <li>NONE</LI> </ul>)^ <p>^A column with TEXT affinity stores all data using storage classes NULL, TEXT or BLOB. ^If numerical data is inserted into a column with TEXT affinity it is converted into text form before being stored.</p> <p>^A column with NUMERIC affinity may contain values using all five storage classes. ^When text data is inserted into a NUMERIC column, the storage class of the text is converted to INTEGER or REAL if that conversion is reversible - if the converversion does not lose information by truncating the value. ^For conversions between TEXT and REAL storage classes, SQLite considers the conversion to be lossless and reversible if the first 15 significant digits of the number are preserved. ^If the lossless conversion of TEXT to INTEGER or REAL is not possible then the value is stored using the TEXT storage class. ^No attempt is made to convert NULL or BLOB values.</p> <p>^A column that uses INTEGER affinity behaves in the same way as a column with NUMERIC affinity, except that if a real value with no fractional component and a magnitude that is less than or equal to the largest possible integer (or text value that converts to such) is inserted it is converted to an integer and stored using the INTEGER storage class. ^Note that a TEXT value inserted into a column with INTEGER affinity will be stored as REAL if there is a lossless conversion to REAL but not a lossless conversion to INTEGER.</p> <p>^A column with REAL affinity behaves like a column with NUMERIC affinity except that it forces integer values into floating point representation. (^As an internal optimization, small floating point values with no fractional component are stored on disk as integers in order to take up less space and are automatically converted back into floating point as the value is read out. ^This optimization is completely invisible at the SQL level and can only be detected by examining the raw bits of the database file.)</p> <p>^A column with affinity NONE does not prefer one storage class over another and no attempt is made to coerce data from one storage class into another.</p> <h3>2.1 Determination Of Column Affinity</h3> <p>^(The affinity of a column is determined by the declared type of the column, according to the following rules in the order shown:)^</p> <ol> <li><p>^If the datatype contains the string "INT" then it is assigned INTEGER affinity.</p> <li><p>^If the datatype of the column contains any of the strings "CHAR", "CLOB", or "TEXT" then that column has TEXT affinity. ^Notice that the type VARCHAR contains the string "CHAR" and is thus assigned TEXT affinity.</p> <li><p>^If the datatype for a column contains the string "BLOB" or if no datatype is specified then the column has affinity NONE.</p> <li><p>^If the datatype for a column contains any of the strings "REAL", "FLOA", or "DOUB" then the column has REAL affinity.</p> <li><p>^Otherwise, the affinity is NUMERIC.</p> </ol> <p>^Note that the order of the rules for determining column affinity is important. ^A column whose declared datatype is "CHARINT" will match both rules 1 and 2 but the first rule takes precedence and so the column affinity will be INTEGER.</p> <h3>2.2 Column Affinity Example</h3> ^(<blockquote> <PRE>CREATE TABLE t1( t TEXT, nu NUMERIC, i INTEGER, no BLOB ); -- Storage classes for the following row: -- TEXT, REAL, INTEGER, TEXT INSERT INTO t1 VALUES('500.0', '500.0', '500.0', '500.0'); -- Storage classes for the following row: -- TEXT, REAL, INTEGER, REAL INSERT INTO t1 VALUES(500.0, 500.0, 500.0, 500.0); </PRE> </blockquote>)^ <a name="comparisons"></a> <h2>3.0 Comparison Expressions</h2> <p>SQLite version 3 has the usual set of SQL comparison operators including "=", "<", "<=", ">=", "!=", "IN", "BETWEEN", and "IS". <p>^(The results of a comparison depend on the storage classes of the operands, according to the following rules:)^</p> <ul> <li><p>^A value with storage class NULL is considered less than any other value (including another value with storage class NULL).</p> <li><p>^An INTEGER or REAL value is less than any TEXT or BLOB value. ^When an INTEGER or REAL is compared to another INTEGER or REAL, a numerical comparison is performed.</p> <li><p>^A TEXT value is less than a BLOB value. ^When two TEXT values are compared an appropriate collating sequence is used to determine the result. </p> <li><p>^When two BLOB values are compared, the result is determined using memcmp().</p> </ul> <p>^SQLite may attempt to convert values between the numeric storage classes (INTEGER and REAL) and TEXT before performing a comparison. ^Whether or not any conversions are attempted before the comparison takes place depends on the affinity of the operands. ^(Affinity is assigned to expression operands by the the following rules:)^ <ul> <li><p>^An expression that is a simple reference to a column value has the same affinity as the column. ^(Note that if X and Y.Z are column names, then +X and +Y.Z are considered expressions.)^</p> <li><p>^(An expression of the form "CAST(<expr> TO <type>)" is assigned an affinity as if it were a reference to a column declared with type <type>)^ </ul> <p>^In a binary comparison, if either operand has INTEGER or REAL or NUMERIC affinity and the other operand does not, then NUMERIC affinity is applied to the other operand before the comparison takes place. ^(The expression "a BETWEEN b AND c" is treated as two separate binary comparisons "a >= b AND a <= c", even if that means different affinities are applied to 'a' in each of the comparisons.)^ ^(Expressions of the form "a IN (SELECT b ....)" are handled is if the expression where really "a=b".)^ ^For example if "b" is a column value and "a" is an expression, then the affinity of "b" is applied to "a" before any comparisons take place. ^(The expression "a IN (x, y, z)" as equivalent to "a = +x OR a = +y OR a = +z".)^ ^The values to the right of the IN operator (the "x", "y", and "z" values in this example) are considered to be expressions, even if they happen to be column values. ^If the value to the left of the IN operator is a column, then the affinity of that column is used. ^If the left operand of IN is an expression then no storage class conversions occur. </p> <h3>3.1 Comparison Example</h3> ^(<blockquote> <PRE> CREATE TABLE t1( a TEXT, b NUMERIC, c BLOB ); |
︙ | ︙ | |||
289 290 291 292 293 294 295 | 0|1 -- Both 60 and 600 (storage class NUMERIC) are less than '500' -- (storage class TEXT). SELECT c < 60, c < 600 FROM t1; 0|0 </PRE> | | | | | | | | < < < < | | | | | | | | | | | | | | < < < < < < < < < < < < < < < < | < | < < | > | | | < < < | < | | | < | | | | | > | | > > | | > | | | < | > > > > < < | < | < | | | > > > > | > > | | | | < | | | | | | | | | | | | | | | | > | > > | | | | | | | | | | | | | | | 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 | 0|1 -- Both 60 and 600 (storage class NUMERIC) are less than '500' -- (storage class TEXT). SELECT c < 60, c < 600 FROM t1; 0|0 </PRE> </blockquote>)^ <h2>4.0 Operators</h2> <p>^(All mathematical operators (which is to say, all operators other than the concatenation operator "||", LIKE, GLOB, MATCH, and REGEXP) apply NUMERIC affinity to both operands prior to being carried out.)^ ^If one or both operands cannot be converted to NUMERIC then the result of the mathematical operation is NULL.</p> <h2>5.0 Sorting, Grouping and Compound SELECTs</h2> <p>^When query results are sorted by an ORDER BY clause, values with storage class NULL come first, followed by INTEGER and REAL values interspersed in numeric order, followed by TEXT values in collating sequence order, and finally BLOB values in memcmp() order. ^No storage class conversions occur before the sort.</p> <p>^When grouping values with the GROUP BY clause values with different storage classes are considered distinct, except for INTEGER and REAL values which are considered equal if they are numerically equal. ^No affinities are applied to any values as the result of a GROUP by clause.</p> <p>^The compound SELECT operators UNION, INTERSECT and EXCEPT perform implicit comparisons between values. ^Before these comparisons are performed an affinity may be applied to each value. ^The same affinity, if any, is applied to all values that may be returned in a single column of the compound SELECT result set. ^The affinity applied is the affinity of the column returned by the left most component SELECTs that has a column value (and not some other kind of expression) in that position. ^If for a given compound SELECT column none of the component SELECTs return a column value, no affinity is applied to the values from that column before they are compared.</p> <tcl>hd_fragment collation {*collating sequence} \ {collating function} *collation *BINARY *NOCASE *RTRIM \ {BINARY collating function} \ {NOCASE collating function} \ {RTRIM collating function}</tcl> <h2>6.0 Collating Sequences</h2> <p>^When SQLite compares two strings, it uses a collating sequence or collating function (two words for the same thing) to determine which string is greater or if the two strings are equal. ^SQLite has three built-in collating functions: BINARY, NOCASE, and RTRIM.</p> <ul> <li>^(<b>BINARY</b> - Compares string data using memcmp(), regardless of text encoding.</li>)^ <li>^(<b>NOCASE</b> - The same as binary, except the 26 upper case characters of ASCII are folded to their lower case equivalents before the comparison is performed.)^ Note that only ASCII characters are case folded. SQLite does not attempt to do full UTF case folding due to the size of the tables required.</li> <li>^(<b>RTRIM</b> - The same as binary, except that trailing space characters are ignored.)^</li> </ul> <p>An application can register additional collating functions using the [sqlite3_create_collation()] interface.</p> <h3>6.1 Assigning Collating Sequences from SQL</h3> <p> ^Every column of every table has an associated collating function. ^If no collating function is explicitly defined, then the collating function defaults to BINARY. ^The COLLATE clause of the [column-def | column definition] is used to define alternative collating functions for a column. </p> <p> ^(The rules for determining which collating function to use for a binary comparison operator (=, <, >, <=, >=, !=, IS, and IS NOT) are as follows and in the order shown:)^ <ol> <li><p>^If either operand has an explicit collating function assignment using the postfix [COLLATE operator], then the explicit collating function is used for comparison, with precedence to the collating function of the left operand.</p></li> <li><p>^If either operand is a column, then the collating function of that column is used with precedence to the left operand. ^For the purposes of the previous sentence, a column name preceded by one or more unary "+" operators is still considered a column name. </p></li> <li><p>^Otherwise, the BINARY collating function is used for comparison. </p></li> </ol> <p> ^The expression "x BETWEEN y and z" is logically equivalent to two comparisons "x >= y AND x <= z" and works with respect to collating functions as if it were two separate comparisons. ^(The expression "x IN (SELECT y ...)" is handled in the same way as the expression "x = y" for the purposes of determining the collating sequence.)^ ^(The collating sequence used for expressions of the form "x IN (y, z, ...)" is the collating sequence of x.)^ </p> <p> ^An ORDER BY clause that is part of a [SELECT] statement may be assigned a collating sequence to be used for the sort operation explicitly. ^In this case the explicit collating sequence is always used. ^Otherwise, if the expression sorted by an ORDER BY clause is a column, then the collating sequence of the column is used to determine sort order. ^If the expression is not a column, then the BINARY collating sequence is used. </p> <h3>6.2 Collation Sequence Examples</h3> <p> The examples below identify the collating sequences that would be used to determine the results of text comparisons that may be performed by various SQL statements. Note that a text comparison may not be required, and no collating sequence used, in the case of numeric, blob or NULL values. </p> ^(<blockquote> <PRE> CREATE TABLE t1( a, -- collating sequence BINARY b COLLATE BINARY, -- collating sequence BINARY c COLLATE RTRIM, -- collating sequence RTRIM d COLLATE NOCASE -- collating sequence NOCASE ); -- Text comparison is performed using the BINARY collating sequence. SELECT a = b FROM t1; -- Text comparison is performed using the RTRIM collating sequence. SELECT a = b COLLATE RTRIM FROM t1; -- Text comparison is performed using the NOCASE collating sequence. SELECT d = a FROM t1; -- Text comparison is performed using the BINARY collating sequence. SELECT a = d FROM t1; -- Text comparison is performed using the RTRIM collating sequence. SELECT 'abc' = c FROM t1; -- Text comparison is performed using the RTRIM collating sequence. SELECT c = 'abc' FROM t1; -- Grouping is performed using the NOCASE collating sequence (i.e. values -- 'abc' and 'ABC' are placed in the same group). SELECT count(*) GROUP BY d FROM t1; -- Grouping is performed using the BINARY collating sequence. SELECT count(*) GROUP BY (d || '') FROM t1; -- Sorting is performed using the RTRIM collating sequence. SELECT * FROM t1 ORDER BY c; -- Sorting is performed using the BINARY collating sequence. SELECT * FROM t1 ORDER BY (c || ''); -- Sorting is performed using the NOCASE collating sequence. SELECT * FROM t1 ORDER BY c COLLATE NOCASE; </PRE> </blockquote>)^ |
Changes to pages/lang.in.
︙ | ︙ | |||
1257 1258 1259 1260 1261 1262 1263 1264 1265 | <p>^(Supported unary prefix operators are these:</p> <blockquote><pre> <font color="#2c2cf0"><big>- + ~ NOT</big></font> </pre></blockquote>)^ <p>^The COLLATE operator can be thought of as a unary postfix operator. ^The COLLATE operator has the highest precedence. | > | | 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 | <p>^(Supported unary prefix operators are these:</p> <blockquote><pre> <font color="#2c2cf0"><big>- + ~ NOT</big></font> </pre></blockquote>)^ <tcl>hd_fragment collateop {COLLATE operator}</tcl> <p>^The COLLATE operator can be thought of as a unary postfix operator. ^The COLLATE operator has the highest precedence. ^It always binds more tightly than any prefix unary operator or any binary operator.</p> <tcl>hd_puts " <p>^The unary operator [Operator +] is a no-op. ^It can be applied to strings, numbers, or blobs and it always gives as its result the value of the operand.</p>"</tcl> |
︙ | ︙ |