Re: [SOLVED] Re: UUID generation problem

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.