> I've been think this for a while too. What about collation? If we add > new chaset A and B, and each has 10 collations then we are going to > have 20 new types? That seems overkill to me.
Well, afaict all of the operations we would ask of a type we will be required to provide for character sets and collations. So ordering, conversions, operators, index methods, etc etc are all required. It *does* seem like a lot of work, but the type system is specifically designed to do exactly this. Lifting those capabilities out of the type system only to reimplement them elsewhere seems all trouble with no upside. Perhaps the current concept of "binary compatible types" could help reduce the complexity, if it were made extensible, which it needs anyway. But in most cases the character set/collation pair is a unique combination, with a limited set of possibilities for other character set/collation pairs with equivalent forms of use, which would keep us from being able to reuse pieces anyway. For most installations, we would install just those character sets the installation/database requires, so in practice the database size need not grow much beyond what it already is. And we could have conventions on how functions and operators are named for a character set and/or collation, so we could auto-generate the SQL definitions given an implementation which meets a template standard. Hmm, an aside which might be relevant: I've been looking at the "national character string" syntax (you know, the N'string' convention) and at the binary and hex string syntax (B'101010' and X'AB1D', as examples) and would like to implement them in the lexer and parser by having the string preceded with a type identifier as though they were something like NATIONAL CHARACTER 'string' BIN '101010' HEX 'AB1D' where both BIN and HEX result in the *same* underlying data type once ingested (or at least a reasonable facimile). I won't be allowed to create two data types with the same type OID, but maybe if I assign them to be binary compatible then I won't have to flesh out the hex data type but only provide an input and output function. - Thomas ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html