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.