On 10/7/20 3:28 PM, Adrian Klaver wrote:
> On 10/7/20 2:24 PM, Rob Sargent wrote:
>>
>>
>> On 10/6/20 9:35 AM, James B. Byrne wrote:
>>> Thank you all for the help. This is what ultimate resolved the issue
>>> for me:
>>>
>>>
>>> [root@accounting-2 ~ (master)]# psql -E --dbname=idempiere
>>> --username=postgres
>>> --host=localhost
>>> Password for user postgres:
>>> psql (11.8)
>>> Type "help" for help.
>>>
>>> idempiere(5432)=# select current_schemas(true);
>>> current_schemas
>>> ---------------------
>>> {pg_catalog,public}
>>> (1 row)
>>>
>>> idempiere(5432)=# ALTER ROLE idempiere_dbadmin SET search_path TO
>>> adempiere,public;
>>> ALTER ROLE
>>>
>>> idempiere(5432)=# \q
>>>
>>> [root@accounting-2 ~ (master)]# psql -E --dbname=idempiere
>>> --username=idempiere_dbadmin --host=localhost
>>> Password for user idempiere_dbadmin:
>>> psql (11.8)
>>> Type "help" for help.
>>>
>>> idempiere(5432)=# select current_schemas(true);
>>> current_schemas
>>> -------------------------------
>>> {pg_catalog,adempiere,public}
>>>
>>>
>> I wonder what affect installing uuid-ossp in template1 /before/
>> starting with the idempiere installation might have had. Such that
>> 'create database idempiere;' would have put all the related functions
>> in place immediately?
>
> Well the issue was not the extension install. It was there. The problem
> was the hide and seek with the search_path. The idempiere_dbadmin role
> had a database setting that overrode the default search_path and
> prevented non-schema qualified calls to the functions to fail for that
> role.
>
>
>
Agreed, but I wasn't sure the idempiere_dbadmin role creation and
uuid-ossp import interleaving didn't have a hand in that effect. But
water under the bridge now.
