#22666: (Generic)IPAddressField index never used on PostgreSQL, inconsistent
behavior
-------------------------------------+-------------------------------------
     Reporter:  intgr                |                    Owner:  nobody
         Type:  Uncategorized        |                   Status:  new
    Component:  Database layer       |                  Version:  1.6
  (models, ORM)                      |               Resolution:
     Severity:  Normal               |             Triage Stage:  Accepted
     Keywords:                       |      Needs documentation:  0
    Has patch:  0                    |  Patch needs improvement:  0
  Needs tests:  0                    |                    UI/UX:  0
Easy pickings:  0                    |
-------------------------------------+-------------------------------------

Comment (by intgr):

 Maybe this illustrates better the behavior I am talking about:

 || ||=Current PG behavior=||=Proposed PG behavior=||=Other
 DBs=||=Comment=||
 ||`__gte`, `__lt`, etc||Textual||Natural||Textual||The only place where
 behavior changes, to be able to use indexes.
 ||order_by||Natural||Natural||Textual||Behavior was always different
 between Postgres and others.
 ||`__contains`||Textual||Textual||Textual||I don't find this useful, but
 since we already have textual `__contains`[[BR]] for integers, it makes
 sense to fo it the same way for inet.

 > If we implement `__contains` to work the same as for integers, the only
 difference between databases would be that sorting is different, right?
 > Another ticket of interest may be #11442 - which in its final resolution
 allows defining custom fields using INET that are not forced through
 `HOST()`

 Uh, so subclasses of GenericIPAddressField with a different name don't
 inherit its behavior? :( It seems we're adding hacks on top of hacks.

 Actually the test introduced in commit
 f7467181aa56e30c946ff55190c49792d6e9a72f points out a problem, it can't be
 done exactly like integers. It seems the `::text` cast appends always the
 netmask, e.g. `/32`. So I guess we still need `host()` for LIKE searches.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/22666#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.fabc87b8b80d504ed922a5fcc6b18d4c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to