Re: [HACKERS] Prefered Types
04.05.2011 0:00, Alvaro Herrera пишет: Excerpts from Зотов Роман's message of mar may 03 16:31:31 -0300 2011: but here we can see problem like 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 PS This patch needet, because in any case we must calc prefer more smartly, yes this patch is 1/10 of full solution, but it`s first step!!! Well, if the other 9/10 were clear, there would be no discussion. The problem is that the missing bits have not been designed and thus we don't know if this 1/10 will be useful to them. We need to find a complete design before committing to any initial portion which may turn out to be bogus down the road. 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 :) -- С уважением, Зотов Роман Владимирович руководитель Отдела разработки ЗАО "НПО Консультант" г.Иваново, ул. Палехская, д. 10 тел./факс: (4932) 41-01-21 mailto: zo...@oe-it.ru -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Prefered Types
03.05.2011 23:06, Tom Lane пишет: I wrote: Alvaro Herrera writes: The interesting discussion is what happens next. To me, this is all related to this previous discussion: http://archives.postgresql.org/pgsql-hackers/2010-09/msg00232.php Yeah, there doesn't seem like much point unless we have a clear idea what we're going to do with the change. BTW, it occurs to me to wonder whether, instead of making types be more or less preferred, we should attack the issue from a different direction and assign preferred-ness ratings to casts. That seems to be more or less the direction that Robert was considering in the above-linked thread. I'm not sure it's better than putting the ratings on types --- in particular, neither viewpoint seems to offer a really clean answer about what to do when trying to resolve a multiple-argument function in which one possible resolution offers a more-preferred conversion for one argument but a less-preferred conversion for another one. But it's an alternative we ought to think about before betting all the chips on generalizing typispreferred. Personally I've always felt that the typispreferred mechanism was a bit of a wart; changing it from a bool to an int won't improve that, it'll just make it a more complicated wart. Casts have already got a standards-blessed notion that some are more equal than others, so maybe attaching preferredness ratings to them will be less of a wart. Not sure about it though. regards, tom lane Now I use this change i manual change preferring of some types (in system tables) and it give me possibility not add some functions clones. I don`t know how (and i think i have no right) to change syntax to use this feature. After many times thinking i find another way to resolve my problem: if function only one we must use Assignment cast rules. But it can help only for me... thats why i think we can change rules to calc prefer like assignment rules have lesser priority, but available. but here we can see problem like F(smallint) F(integer) but call like F(float) i wouldn`t like to fail it. PS This patch needet, because in any case we must calc prefer more smartly, yes this patch is 1/10 of full solution, but it`s first step!!! -- С уважением, Зотов Роман Владимирович руководитель Отдела разработки ЗАО "НПО Консультант" г.Иваново, ул. Палехская, д. 10 тел./факс: (4932) 41-01-21 mailto: zo...@oe-it.ru -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
