PostgreSQL 8.3 and casting

[Jeremy Dunck]

Prior to PostgreSQL 8.3, non-text types were implicitly converted to text.

This allowed things like the following:

class Log(models.Model):
actor = models.CharField(...)

>>> Log.objects.filter(actor=1).count()

===

With 8.3, this fails because there's no operator between text and integer.

I see that the Oracle backend already includes
OracleQueryconvert_values which does conversion into the backend based
on the the passed value and the field type.

Perhaps we need to add that for PostgreSQL now? It's pretty onerous
to do the casting at the app level.

Am I missing something? I was a bit surprised to find no similar
complaints on the mailing list. :)

[Karen Tracey]

There was this discussion:

http://groups.google.com/group/django-developers/browse_thread/thread/371e8743fffd3d0c/1e5d3f777e3fd699

Karen

[Justin Bronn]

> I see that the Oracle backend already includes
> OracleQueryconvert_values which does conversion into the backend based
> on the the passed value and the field type.
>
> Perhaps we need to add that for PostgreSQL now?  It's pretty onerous
> to do the casting at the app level.
>

The `convert_values` routine is only used on values coming _from_ the
database (via `resolve_columns`), and not on values going _to_ the
database. I'm with Malcolm on not supporting this feature of
automatically casting to string because the database is doing the
"right thing" here. [1]

However, I believe there are still parts of Django that depend on this
behavior -- for instance adding a search field to a related field in
the admin is one of these situations (I need to provide specifics, but
don't have it on hand at the moment).

[1] See http://groups.google.com/group/django-developers/browse_frm/thread/371e8743fffd3d0c.
See also: http://code.djangoproject.com/ticket/6523.

[J Meier]

On May 20, 9:01 am, Justin Bronn <jbr...@gmail.com> wrote:
> I'm with Malcolm on not supporting this feature of
> automatically casting to string because the database is doing the
> "right thing" here. [1]

It's certainly the right thing to do in general.

I'd like to mention one use of the implicit conversion performed by
older PostgreSQL versions that I'm making use of, and others might
unknowingly also: Using a CharField or SlugField as the object_id
field of a generic foreign key. This allows the key to relate to both
string-keyed objects and integer-keyed objects. This is fairly gross
DB design; in my app it could be worked around by using surrogate ID
keys (along with a lot of data munging, but that's automatable). The
problem comes with targeting a generic foreign key at models from
third party apps, over whose keys users don't have control.

There's certainly a fix for the situation, either something simple
that I've missed or perhaps adding a shim to explicitly coerce values
only for desired cases.

-Jim