#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.