Обсуждение: 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