t == tgl@sss.pgh.pa.us writes:
t> Brandon Metcalf <brandon@geronimoalloys.com> writes:
t> > d == dalroi@solfertje.student.utwente.nl 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