On Thu, Apr 29, 2004 at 08:52:08AM -0700, Dean Arnold wrote: > > On Wed, Apr 28, 2004 at 11:17:30PM -0700, Dean Arnold wrote: > > > > > > I found an ISO SQL spec (for SQL-99 anyway... > > > has DBI declared any conformance level at this point ?) > > > > No. Though basically it tried to track the latest standards. > > > > > And my interpretations of type string formats seem pretty > > > conformant. However, the "exotics", e.g. ROW, GUID, UDT, > > > etc. will likely have only generic defaults for obvious reasons > > > (questions? just read the spec), but INTERVAL defaults > > > will behave pretty much as I described. > > > > > > Quick poll: how many drivers supply a PRECISION value for > > > INTEGER, REAL, FLOAT, DOUBLE PRECISION ? The std. > > > indicates they can have precision... > > > > How many drivers provide _accurate_ PRECISION for all those types? > > > > And how many databases accept having a PRECISION specified for those types? > > > > And for FLOAT types is PRECISION in the same units as the FLOAT(n) > > parameter? (For float types some databases specify PRECISION in > > decimal digits and some in binary digits, and some change between > > versions :) > > > > Originally you said "either for display purposes, or to generate > > additional queries". Display purposes is fine, you can do anything > > 'reasonable' but "generate additional queries" is a far more demanding > > requirement. It's important to specify *exactly* what the goal is. > > > > And what about modifiers like UNSIGNED, or even AUTO_UNIQUE_VALUE. > > > > Tim. > > Actually I would hope that *both* display and query generation would be > possible; in fact, the former should be satisfied by the latter.
Of course. > My question/efforts are related to default implementation to support > drivers which don't implement a driver specific version. > > So should a default implemenation even be provided if it can't > safely meet the 2nd requirement (query generation) ? That's only relevant if "accurate enough for query generation" (presumably 'create table' statements) is defined as a goal of the method. Alternatively we could go for a looser specification more like: Describes the type in a form as similar as possible to that which would be used to define a column with the same type in a create table statement. In practice it's likely that only simple types will be accurate, some types may produce invalid syntax, and some types may lack detail. Arguably the same kind of functionality should be available for type_info() data. And arguably the statement handle metadata should be available as a per-column hash. So it might be nice to offer a method that can be given either a type_info() hash of a per-column statement handle metadata hash and return the type string. > I'm not certain > DBI specifies enough metadata to completely generate defaults > that can be safely used in query generation (eg, CASESPECIFIC, > CHARACTER SET, in addition to those listed by Tim) > And the exotic types (ROW, UDT, etc) certainly couldn't be fully generated > from the existing metadata. The DBI's default method would err on the cautious side. Drivers can add their own with more detail for specific types they want. Tim.
