Re: SQL_SIZING view - Mailing list pgsql-hackers
From | Rod Taylor |
---|---|
Subject | Re: SQL_SIZING view |
Date | |
Msg-id | 1041890363.31370.101.camel@jester Whole thread Raw |
In response to | SQL_SIZING view (Peter Eisentraut <peter_e@gmx.net>) |
List | pgsql-hackers |
According to: http://www.itl.nist.gov/fipspubs/fip127-2.htm#FIPS_TOP 15.2 SQL_Sizing table. The SQL_SIZING table shall consist of exactly one row for each FIPS SQL database construct defined in Section 16.6 of this standard. The SIZING_ID and DESCRIPTION columns identify the database construct by the integer and description assigned to it in Section 16.6. The ENTRY_VALUE column is equal to the default Entry SQL value defined for that construct by FIPS SQL in Section 16.6, with "*" converted to a Null value. The INTERMEDIATE_VALUE column is equal to the default Intermediate SQL value defined for that construct by FIPS SQL in Section 16.6, with "*" converted to a Null value. The VALUE_SUPPORTED column indicates a value for the construct that is supported by an implementation when data in the identified catalog is accessed through that implementation; if this value is Null, then there is no explicit restriction on the size of that construct. A user must be able to depend upon these values when executing SQL-statements against data in the catalog. If a given catalog spans multiple SQL-Server implementations, then the VALUE_SUPPORTED shall be valid in all of them. It is important to recognize that FIPS sizing defaults are not requirements for conformance to FIPS SQL; instead, they identify a default value that is assumed to be specified if a Federal SQL procurement is silent on that topic. For this reason, the VALUE_SUPPORTED may sometimes be less than the FIPS default for the ENTRY_VALUE or the INTERMEDIATE_VALUE, even for a FIPS SQL conforming implementation. The SIZING_COMMENTS column is intended for any vendor comments pertinent to the identified FIPS SQL database construct. 16.6 Sizing for database constructs. References to this standard in a procurement should indicate minimum requirements for the precision, size, or number of occurrences of database constructs. Failure to make this indication means that the Entry Values detailed below are by default the minimum requirements for Entry SQL or Transitional SQL procurements and the Intermediate Values detailed below are by default the minimum requirements for Intermediate SQL or Full SQL procurements. Sizing Entry Interm. Id Description Value Value 1. Length of an identifier 18 128 2 CHARACTER max length 240 1000 3. CHARACTER VARYING max length 254 1000 4. BIT max length in bits * 8000 5. BIT VARYING max length in bits * 8000 6. NATIONALCHARACTER max length * 500 7. NATIONAL CHAR VARYING max length * 500 8. NUMERIC decimal precision 15 15 9. DECIMAL decimal precision 15 15 10. INTEGER decimal precision 9 * 11. INTEGER binaryprecision * 31 12. SMALLINT decimal precision 4 * 13. SMALLINT binary precision * 15 14. FLOAT binary mantissa precision 20 47 15. FLOAT binary exponent precision * 9 16. REAL binary mantissa precision 20 23 17. REAL binary exponent precision * 7 18. DOUBLEPRECISION binary mantissa precision 30 47 19. DOUBLE PRECISION binary exponent precision * 9 20. TIME decimal fractional second precision * 0 21. TIMESTAMP decimal fractional secondprecision * 6 22. INTERVAL decimal fractional second precision * 6 23. INTERVAL decimalleading field precision * 7 24. Columns in a table 100 250 25. Values in an INSERT statement 100 250 26. Set clauses in UPDATE statement 20 250 27. Length of a row (see Note 1) 2000 8000 28. Columns in UNIQUE constraint 6 15 29. Length of UNIQUE columns (Note 1) 120 750 30.Columns in GROUP BY column list 6 15 31. Length of GROUP BY column list (Note 1) 120 750 32. Sort items in ORDER BY clause 6 15 33. Length of ORDER BY column list(Note 1) 120 750 34. Referencing columns in FOREIGN KEY 6 15 35. Length ofFOREIGN KEY column list (Note 1) 120 750 36. Table references in an SQL statement (Note 3) 15 50 37. Cursors simultaneously open 10 100 38. WHEN clauses in a CASE expression * 50 39. Columns in a named columns JOIN * 15 40. Length of JOIN columnlist (Note 1) * 750 41. Items in a SELECT list 100 250 42.Length of SQL (Note 2) * 30000 43. Length of (Note 2) * 4000 44. Length of (Note 2) * 4000 45. Occurrences in an ALLOCATE DESCRIPTOR * 100 46. Default occurrences in ALLOCATE DESCRIPTOR * 100 Note 1: The length of a collection of columns is conservatively estimated to be no larger than the sum of: twicethe number of columns,OCTET_LENGTH of each character or bit column (see Subclause 6.6, (numeric value function),of X3.135-1992), decimal precision plus 1 of each exact numeric column, binary precision divided by4 plus 1 of each approximate numeric column, 10 for each DATE column, 8 for each TIME column, 14 for each TIMEWITH TIME ZONE column, 19 for each TIMESTAMP column, 25 for each TIMESTAMP WITH TIME ZONE column, and 20 for each INTERVAL column. In addition, if any DATE, TIME, TIMESTAMP, or INTERVAL column has a non-zero fractionalseconds precision, then add that precision plus 1 to the length of the column. Note2: The length of an SQL statement is defined to be the result of applying the OCTET_LENGTH function (see Subclause6.6, (numeric value function), of X3.135-1992) to the SQL statement with the SQL statement consideredto be an instance of a CHARACTER VARYING data type. Note 3: The number of table referencesin an SQL statement is the sum of: the number of views and base tables named in the statement, thenumber of underlying views and tables (see Subclause 4.9, "Tables", of X3.135-1992) for each derived table or cursor, and the number of ) (either given in the SQL statement or contained in some view named in the SQL statement) not directly associated with a named table or view. Some applications may have requirements for CHARACTER VARYING or BIT VARYING data types with lengths much longer than the Entry SQL or Intermediate SQL values specified above. This is particularly true for applications that need to manage large Audio, Graphics, Text, or Video objects. Some applications have requirements for Audio, Text, or Graphics objects in excess of 2-3 million bytes, or Video objects in excess of multiple gigabytes. Implementations that provide such data types often impose severe restrictions in how these very large objects can be referenced in SQL definitions and statements. For example, a very long CHARACTER VARYING data type may not be allowed to participate in a PRIMARY KEY, a UNIQUE constraint, a REFERENTIAL constraint, a ) a GROUP BY or HAVING clause, or an ORDER BY in a cursor definition. Applications that stay within the limits specified above should not encounter any unexpected restrictions in how these constructs can be used or referenced in SQL language. Some implementations address user requirements for very large objects, with a minimum number of restrictions, by allowing arbitrarily large maximum length declarations for CHARACTER VARYING or BIT VARYING, with an internal representation using some sort of indirect addressing mechanism. In this way they can keep the physical length of the row in which the object is represented less than the physical page size of the operating system environment, often necessary for lock management, while at the same time meet user requirements for storing, retrieving, and managing large objects. SQL procurements that anticipate requirements for very long CHARACTER VARYING or BIT VARYING data types should be very explicit in procurement specifications about additional requirements for how these large data types interface to external processors or how they need to be processed by SQL language. On Mon, 2003-01-06 at 13:48, Peter Eisentraut wrote: > The information schema is supposed to contain a view SQL_SIZING which is > defined thus: > > List the sizing items defined in this standard and, for each of > these, indicate the size supported by the SQL-implementation. > > But the standard does not define any "sizing item" or anything like that > anywhere. > > Unless someone can offer an explanation, I am inclined to just supply an > empty table and check off this item. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
pgsql-hackers by date: