On Fri, Oct 23, 2009 at 11:14 AM, Kareem Sedki <isiscreation@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
