# Search within topic is omitting results

**URL:** https://meta.discourse.org/t/search-within-topic-is-omitting-results/42982
**Category:** Bug
**Created:** [22. April 2016 um 11:07 UTC](https://meta.discourse.org/t/search-within-topic-is-omitting-results/42982 "2016-04-22T11:07:21Z")
**Posts on this page:** 1
**Showing post:** 18

<div class="post-metadata">

### Author: ![Mittineague](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mittineague/32/114259_2.png) [@Mittineague](https://meta.discourse.org/u/Mittineague)
#### Post date: [1. Mai 2016 um 20:30 UTC](https://meta.discourse.org/t/search-within-topic-is-omitting-results/42982/18 "2016-05-01T20:30:10Z")

</div>

I’ve been thinking of various ways to solve the problem.

1: change lib/search.rb line 484

```plaintext
posts = posts.where("posts.raw || ' ' || u.username || ' ' || u.name ilike ?", "%#{@term}%")

```

to simply not test against users.name  
Works, but eg. will not match searches for “Atwood” with “codinghorror”

2: add conditional  
` if null do this else if not null do this`  
Feels like bloat to me.

3: change lib/search.rb line 484 to

```plaintext
posts = posts.where("posts.raw || ' ' || u.username || ' ' || quote_nullable(u.name) ilike ?", "%#{@term}%")

```

This essentially changes a NULL into the text string “NULL”  
One possible drawback is if one were to search for the string “NULL” it would find posts by such members.  
But IMHO this would be extreme edge case and I feel adding `quote_nullable` would suffice and eliminate any need to make code changes elsewhere.

> **[41.5. Basic Statements](https://www.postgresql.org/docs/9.1/plpgsql-statements.html)**
>
> 41.5. Basic Statements # 41.5.1. Assignment 41.5.2. Executing SQL Commands 41.5.3. Executing a Command with a Single-Row Result 41.5.4. Executing Dynamic …

Tested on localhost and no side effects that I could see.

---

_[View the full topic](https://meta.discourse.org/t/search-within-topic-is-omitting-results/42982)._