Re: How to check whether a data type can be cast to another

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(at)gmail(dot)com> 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
>