Re: "interesting" issue with restore from a pg_dump with a database-wide search_path
От | Tom Lane |
---|---|
Тема | Re: "interesting" issue with restore from a pg_dump with a database-wide search_path |
Дата | |
Msg-id | 5130.1532385403@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: "interesting" issue with restore from a pg_dump with a database-wide search_path ("Regina Obe" <lr@pcorp.us>) |
Ответы |
RE: "interesting" issue with restore from a pg_dump with a database-wide search_path
|
Список | pgsql-hackers |
"Regina Obe" <lr@pcorp.us> writes: > Sorry for not posting from the thread. Paul alerted me to this one and I am aware of the issue. > 1) I do have fuzzstrmatch listed as a dependency in the control file. I know because I often install the geocoder with > CREATE EXTENSION postgis_tiger_geocoder CASCADE; > And it installs postgis and fuzzystrmatch OK. > a) In this particular case, I have a function that uses fuzzystrmatch and is used in functional indexes. > I unfortunately can't schema qualify the use of soundex, because I don't know where the user may have installed fuzzystrmatchis installed > b) Stephen Frost had suggested, perhaps we should have some syntax like @extension_loc(fuzzystrmatch)...@ so that one couldreference an extension dependency location within a function without knowing where it is installed. You don't really need any new syntax for this particular case, I think. You can declare the function in the extension like this: create function ... set search_path from current; which will cause it to absorb the search path that's set while running the extension script, which should be what you want. regards, tom lane
В списке pgsql-hackers по дате отправления: