Re: operator varchar = integer
| От | Tino Wildenhain |
|---|---|
| Тема | Re: operator varchar = integer |
| Дата | |
| Msg-id | 481F2CF5.80400@wildenhain.de обсуждение исходный текст |
| Ответ на | Re: operator varchar = integer (Daniel Schuchardt <daniel_schuchardt@web.de>) |
| Ответы |
Re: operator varchar = integer
|
| Список | pgsql-general |
Hi, Daniel Schuchardt wrote: > David Fetter schrieb: >> That technical debt is a risk to your whole project, and you need to >> dedicate resources to paying it down. >> >> <http://en.wikipedia.org/wiki/Technical_debt> >> >> There are ways to get those automated casts, but they will only make >> your situation worse in the long run. >> >> Cheers, >> David. >> > > *g* interesting standpoint and your right but: > > it is impossible for us to find all the points where the new 8.3 > behavoir would crash at the first time. so our next versions would be > very buggy and our customers wouldn't be happy ;-) > the next problem is that our service personal has to be traineed too; > they dont know much about casting, 81 does it automatically; problems > problems problems. > > if it is not possible (i know it is) ;-) to recreate automatic casts in > 83 we would not be able to upgrade to 83 the next years. the next > possible date would be in about 3-4 years with the next major release. > > PS: > our db has about 500 functions, 300 tables, 1000 indexes, 1200 Views > that all use implicit casting. > and: everything is working fine ;-) :-P > > so we have to choose another way. Well err... implicit table joining is also off per default I believe. So if you had used it a lot you would have a similar problem. Comparing int with text in general does not sound like a very good idea to me. It should be quite easy to write a script to identify such places so you can either change the datatypes (preferred) or add the cast. Then rerun your automated regression tests... Cheers T.
Вложения
В списке pgsql-general по дате отправления: