t == tgl@xxxxxxxxxxxxx writes: t> Brandon Metcalf <brandon@xxxxxxxxxxxxxxxxxx> writes: t> > d == dalroi@xxxxxxxxxxxxxxxxxxxxxxxxxxxx writes: t> > d> On May 26, 2009, at 6:37 PM, Brandon Metcalf wrote: t> > d> > The issue here is that these reduce back to my original problem. For t> > d> > example, if I use a CASE statement and I fall through to the ELSE, t> > d> > then the SQL is attempting to insert a "''" in a NUMERIC field which t> > d> > is not valid. That is, it's trying to do t> > d> No it doesn't, read that statement again ;) t> > Oops. Indeed, you are correct. t> I think there is a problem though. If you have t> case when '$length'='' then length else '$length' end t> then what the parser is going to see is a CASE expression with a t> variable (known to be NUMERIC) in one arm and an unknown-type literal t> constant in the other arm. So it's going to decide that the literal t> must be NUMERIC too, and that type coercion will fail if the literal t> is really just ''. t> Some experimentation suggests that you might get away with t> case when '$length'='' then length else '$length'::text::numeric end I think this is what I meant to say :) If $length contains a number, then the resulting statement will be $length = '5.8', for example, and this will fail for type NUMERIC. -- Brandon -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
