#31304: PostgreSQL full-text search employs coalesce function for non-null
single-
column searches with SearchVector
-------------------------------------+-------------------------------------
Reporter: Paul Boddie | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 2.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: PostgreSQL text | Triage Stage: Accepted
search FTS coalesce SearchVector |
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* cc: Simon Charette (added)
Comment:
> I wouldn't expect to_tsvector to treat an empty string and null in the
same way - this being SQL after all - but the aim would be to avoid
coalesce where null could never occur. This then becomes an issue of
knowing when this might be guaranteed.
Right the main issue here is that `SearchVector` (just like `Concat` for
example) has been coalescing nulls to empty strings forever so we can't
just change it now without breaking backward compatibility.
> I'm still getting familiar with the ORM, but I imagine that there could
easily be cases where column values are null even if the table columns are
declared not null. For instance, any query involving an outer join could
produce null values for a "not null" column. In such cases, the
characteristics of the output column would need to be defined by
identifying its role in the query, pretty much as you say.
Right comment:6 provides another example of that. The `JOIN` resolution
logic knows about these things but it's not surfaced at the `Expression`
introspection level right now so we can't even start deprecating the
current behaviour if we wanted to. I plan on working on patch that exposes
an `Expression.nullable` property that gets assigned on field reference
resolution but that's not an easy thing to get right as you might suspect.
> I am inclined to think that making my own lookup would be the safest
thing to do for now, with the lookups provided also considering the issue
of transferring the configuration.
I tend to agree, are you still interested in submitting a PR that does a
`config` assignment in `SearchLookup.process_lhs`?
--
Ticket URL: <https://code.djangoproject.com/ticket/31304#comment:8>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.3375398e62ee8949a533392ed4bfb3b4%40djangoproject.com.
