fix: don't ERROR if paradedb.terms_with_operator is missing
#3013
Conversation
It's possible that when upgrading pg_search from `v0.15.26` to `v0.17.x` we could generate an ERROR complaining that `paradedb.terms_with_operator(...)` doesn't exist if the user upgraded the extension binary but has not yet run `ALTER EXTENSION pg_search UPDATE;`. This fixes that by inspecting the catalogs directly when it's necessary to lookup that function and plumbing through an `Option<pg_sys::Oid>` return value.
I don't understand. What in this PR do you believe will or should eventually be deleted? |
Nothing, because this PR is bound for |
|
I'm sorry. What conditionals? There's nothing in this PR that adds code we might remove later. What it does is makes the current code resilient in the face of a schema object not existing. |
|
|
I see...
technically, yes.
In this case, if for whatever reason the function doesn't exist we can't produce a custom scan that requires that function, so we should either produce a different custom scan or no custom scan. We probably shouldn't ERROR. As you can see in the regression test in this PR, it is possible for a superuser to just drop the function entirely. Maybe they should get what they deserve in that case but we can still successfully get their query answered with basically a few For my own sanity I'm internally rationalizing this PR not as "let us upgrade from 0.15.26 cleanly" but "let us be resilient when the schema doesn't match our expectations." And I don't think resiliency is something we'd want to later revert. In fact, I intend to do more of this as part of cherry-picking this to |
Cherry picks PR #3013, which only landed in 0.17.x, to `main` and `0.18.x` via the label.
Cherry picks PR #3013, which only landed in 0.17.x, to `main` and `0.18.x` via the label.
Cherry picks PR #3013, which only landed in 0.17.x, to `main` and `0.18.x` via the label. --------- Co-authored-by: Eric Ridge <eebbrr@gmail.com> Co-authored-by: Eric B. Ridge <eebbrr@paradedb.com>
Ticket(s) Closed
What
It's possible that when upgrading pg_search from
v0.15.26tov0.17.xwe could generate an ERROR complaining thatparadedb.terms_with_operator(...)doesn't exist if the user upgraded the extension binary but has not yet runALTER EXTENSION pg_search UPDATE;.This fixes that by inspecting the catalogs directly when it's necessary to lookup that function and plumbing through an
Option<pg_sys::Oid>return value.Why
To help users/customers/partners better deal with upgrading from really old pg_search versions.
How
Tests
Existing tests pass, especially the ones added in #2730, and a new regress test has been added that explicitly removes the function from the schema and ensures the query still works (tho with a different plan, of course).