Well, actually, yes our work is based on an EAV
model. And it has been successful so far. However, the point I was
discussing is not really dependent on the EAV model. It is rather
dependent on the fact that we are employing an object-oriented design
implemented on top of an RDBMS. Regarding, the fully-typed system point. In fact, if you allow types to be automatically defined and constrained by priorly defined rules of suitability for what should define a type and how a type may behave when input to typing functions (type-test functions), an EAV may be fully-typed. This doesn't apply only to EAV model. A further step would be making the suitability rules automatically inferred from existing types if possibles. Regarding the cast thing I was asking about, I guess we can get away with a constraint on the field's type (which was supposed to be polymorphic) and handle polymorphic issues in the dynamic parts of the systems rather than in static structures, such as, tables. Thank you very much, Merlin and Tom. I appreciate you suggestions and help. Kind Regards, Kareem Sedki On 10/23/2009 05:24 PM, Tom Lane wrote: Kareem Sedki <isiscreation@xxxxxxxxx> writes:The problem I faced is that the type 'any' is not permitted in procedural languages. If it were permitted, then we could have a function like is_castable( value ANY, target_type TEXT) and then we would catch exceptions if they are thrown.ANYELEMENT maybe?Here is what we have, there is a field in which we should store different data types and another field in the same row to store the identifier of the original data type of the first field. The first field should be polymorphic.Although actually I think you should stop right here and rethink what you are doing. It sounds a whole lot to me like you are trying to build an EAV store, and that seldom leads to anything good. It is much better to spend the necessary effort up-front to work out a concrete fully-typed schema for your database. regards, tom lane |