On Fri, Oct 23, 2009 at 11:14 AM, Kareem Sedki <isiscreation@gmail.com> wrote:
> Thank you Merlin and Tom. I appreciate your answers.
>
> I have tried to follow that approach before I go this way. So, I checked the
> appendix of the documentation for error conditions. Searching for
> cast-related conditions, I found INVALID_CHARACTER_VALUE_FOR_CAST. Would
> that be the exception to catch? It doesn't sound right.
>
> 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. We didn't want to begin working on C functions before
> the prototype is complete. However, if this is the only way, C is the way
> to go for now then.
>
> If we can, programmatically, figure out whether a type can be cast to
> another, we can then check each type's limits or valid values to consider
> the valid.
>
> 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. Since I couldn't find how to make a field polymorphic, I
> resorted to a 'text' field so that different data types can be stored in the
> field after being cast to 'text'. When retrieving a field, its original
> state should be cast back from 'text'.
>
> Do you think of a better strategy?
I think Tom is probably giving you the right advice here. However,
if you decide to implement something around my 'catch the error'
approach (i was half joking when I suggested it), it should be a
simple matter to test a few and print out (raise notice) the sqlstate
variable inside the exception handler.
merlin
