ProgrammingError with PostgreSQL: operator does not exist: integer ~~* unknown
I get the same problem as described here: #6523 http://code.djangoproject.com/ticket/6523 There is a diff file which says it fixes the problem, how should I proceed? If implement the diff, anyone care to tell me how please. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: ProgrammingError with PostgreSQL: operator does not exist: integer ~~* unknown
On Fri, 2008-04-18 at 17:26 -0700, Merrick wrote: > I get the same problem as described here: > > #6523 > http://code.djangoproject.com/ticket/6523 > > There is a diff file which says it fixes the problem, how should I > proceed? If implement the diff, anyone care to tell me how please. We had a discussion about this behaviour on the dev list a while back and have decided that using inappropriate operators on the wrong field types (e.g. using LIKE on an integer) is just not going to work if the database doesn't auto-case. It's actually bad data design to rely on that and Django shouldn't have to carry the overhead for working around that (it would be extra overhead for every database backend, since every time the operator is used, we need to do a check for the backend type and then change the behaviour). Using casts everywhere at the database level also slows down query time quite a bit and, again, we aren't going to penalise people who are doing the right thing to accommodate those with bad design. Basically PostgreSQL 8.3 has started reporting an error for something that has always been more or less an error, but has been previously disguised. However, we still need to audit the internal uses to make sure we aren't inadvertently using these wrong types ourselves, which is why #6523 (and, related, #6605) are still open. The short answer is to work out why you are trying to use these text-based operators on non-text fields and avoid doing that. It's wrong. However, it may not be your fault if it's something Django is doing, which is part of fixing that problem. Regards, Malcolm -- If it walks out of your refrigerator, LET IT GO!! http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: ProgrammingError with PostgreSQL: operator does not exist: integer ~~* unknown
I understand what you are saying the problem is. In my case here is what sets this off: class Meta: unique_together = ('city', 'title',) where city is a foreign key and now I see the mixed types. On Apr 18, 8:58 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Fri, 2008-04-18 at 17:26 -0700, Merrick wrote: > > I get the same problem as described here: > > > #6523 > >http://code.djangoproject.com/ticket/6523 > > > There is a diff file which says it fixes the problem, how should I > > proceed? If implement the diff, anyone care to tell me how please. > > We had a discussion about this behaviour on the dev list a while back > and have decided that using inappropriate operators on the wrong field > types (e.g. using LIKE on an integer) is just not going to work if the > database doesn't auto-case. It's actually bad data design to rely on > that and Django shouldn't have to carry the overhead for working around > that (it would be extra overhead for every database backend, since every > time the operator is used, we need to do a check for the backend type > and then change the behaviour). Using casts everywhere at the database > level also slows down query time quite a bit and, again, we aren't going > to penalise people who are doing the right thing to accommodate those > with bad design. Basically PostgreSQL 8.3 has started reporting an error > for something that has always been more or less an error, but has been > previously disguised. > > However, we still need to audit the internal uses to make sure we aren't > inadvertently using these wrong types ourselves, which is why #6523 > (and, related, #6605) are still open. > > The short answer is to work out why you are trying to use these > text-based operators on non-text fields and avoid doing that. It's > wrong. However, it may not be your fault if it's something Django is > doing, which is part of fixing that problem. > > Regards, > Malcolm > > -- > If it walks out of your refrigerator, LET IT > GO!!http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---