Обсуждение: Re: unaccent(text) fails depending on search_path (WAS: pg_upgrade fails saying function unaccent(text) doesn't exist)
[ redirecting to pgsql-hackers ] I wrote: > Gunnlaugur Thor Briem <gunnlaugur@gmail.com> writes: >> SET search_path = "$user"; SELECT public.unaccent('foo'); >> SET >> ERROR: text search dictionary "unaccent" does not exist > Meh. I think we need the attached, or something just about like it. > > It's barely possible that there's somebody out there who's relying on > setting the search path to allow choosing among multiple "unaccent" > dictionaries. But there are way more people whose functions are > broken due to the recent search-path-tightening changes. Here's a slightly more efficient version. regards, tom lane diff --git a/contrib/unaccent/unaccent.c b/contrib/unaccent/unaccent.c index 247c202..dbf2bb9 100644 *** a/contrib/unaccent/unaccent.c --- b/contrib/unaccent/unaccent.c *************** *** 20,26 **** --- 20,28 ---- #include "tsearch/ts_locale.h" #include "tsearch/ts_public.h" #include "utils/builtins.h" + #include "utils/lsyscache.h" #include "utils/regproc.h" + #include "utils/syscache.h" PG_MODULE_MAGIC; *************** unaccent_dict(PG_FUNCTION_ARGS) *** 376,382 **** if (PG_NARGS() == 1) { ! dictOid = get_ts_dict_oid(stringToQualifiedNameList("unaccent"), false); strArg = 0; } else --- 378,398 ---- if (PG_NARGS() == 1) { ! /* ! * Use the "unaccent" dictionary that is in the same schema that this ! * function is in. ! */ ! Oid procnspid = get_func_namespace(fcinfo->flinfo->fn_oid); ! const char *dictname = "unaccent"; ! ! dictOid = GetSysCacheOid2(TSDICTNAMENSP, ! PointerGetDatum(dictname), ! ObjectIdGetDatum(procnspid)); ! if (!OidIsValid(dictOid)) ! ereport(ERROR, ! (errcode(ERRCODE_UNDEFINED_OBJECT), ! errmsg("text search dictionary \"%s.%s\" does not exist", ! get_namespace_name(procnspid), dictname))); strArg = 0; } else
On Wed, Sep 5, 2018 at 06:37:00PM -0400, Tom Lane wrote: > [ redirecting to pgsql-hackers ] > > I wrote: > > Gunnlaugur Thor Briem <gunnlaugur@gmail.com> writes: > >> SET search_path = "$user"; SELECT public.unaccent('foo'); > >> SET > >> ERROR: text search dictionary "unaccent" does not exist > > > Meh. I think we need the attached, or something just about like it. > > > > It's barely possible that there's somebody out there who's relying on > > setting the search path to allow choosing among multiple "unaccent" > > dictionaries. But there are way more people whose functions are > > broken due to the recent search-path-tightening changes. > > Here's a slightly more efficient version. If we are going down this route, is there any thought of handling earchdistance the same way? https://www.postgresql.org/message-id/20180330205229.GS8476@momjian.us -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes: > If we are going down this route, is there any thought of handling > earchdistance the same way? > https://www.postgresql.org/message-id/20180330205229.GS8476@momjian.us AFAICS there are no internal-to-the-C-code search path dependencies in earthdistance.c, so it's not the same problem. regards, tom lane
On Fri, Sep 7, 2018 at 06:43:52PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > If we are going down this route, is there any thought of handling > > earchdistance the same way? > > https://www.postgresql.org/message-id/20180330205229.GS8476@momjian.us > > AFAICS there are no internal-to-the-C-code search path dependencies > in earthdistance.c, so it's not the same problem. Uh, there is an SQL function that calls functions from the module that fail. It would be a CREATE FUNCTION patch, I think, but I thought the issue was the same. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes: > On Fri, Sep 7, 2018 at 06:43:52PM -0400, Tom Lane wrote: >> AFAICS there are no internal-to-the-C-code search path dependencies >> in earthdistance.c, so it's not the same problem. > Uh, there is an SQL function that calls functions from the module that > fail. It would be a CREATE FUNCTION patch, I think, but I thought the > issue was the same. Not really. You could either interpolate @extschema@ into the text of the referencing function, or (though much inferior for performance) have it SET SEARCH_PATH FROM CURRENT. Either of those changes would involve an extension version bump since they're changing the extension script. What's more of a problem is that we could no longer claim the extension is relocatable. My unaccent fix dodged that by looking up the C function's current schema, but I don't think there's any equivalent functionality available at SQL level. regards, tom lane