On May 4, 2011, at 12:00 AM, Зотов Роман wrote: >>> F(smallint) >>> F(integer) >>> but call like F(float) >>> i wouldn`t like to fail it. >> I think this particular example would be a mistake, because that cast >> would be lossy, so you want to invoke it only when the user explicitely >> selects it. The other way around would be fine, I think, that is, >> F(float) >> F(float8) >> and the call is F(int) > As i think i not must write function with Float, String, and many other arg > when my function have INT arg... and if caller wouln`t think about types he > cant use your strong types > why it not must work like as assignment??? why implicit and assignment is > different??? > I know only implicit and explicit casts and i think imlicit=asssign
I was ready to educate Зотов on why that was a bad idea until I read... > Yes, but while you think what update table1 set IntField = FloatField is valid > but Select FuncWithIntArg(FloatArg) is not valid > you have no problems in current solution, because it works same :) Sure enough, this works: UPDATE ... SET int_field = ( SELECT float_field FROM ... ); Which begs the question... why do we allow on assignment casting of a float to an int? I would think that should be explicit only... If we are going to allow assignment casting of float to int, then I'm hard-pressed to see why we wouldn't allow you to call an int function with a float value, assuming there wasn't a more suitable cast available. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
