Re: UUID generation problem

From: Paul Förster <paul(dot)foerster(at)gmail(dot)com>
To: byrnejb(at)harte-lyne(dot)ca
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: UUID generation problem
Date: 2020-10-05 17:34:56
Message-ID: B162B0E3-BB52-4748-96F7-93561795E8B6@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi James,

> On 05. Oct, 2020, at 19:16, James B. Byrne <byrnejb(at)harte-lyne(dot)ca> wrote:
>
> As this is an application package it is not within my purview to alter the
> code. To do so would rik a return of the problem with every update.
>
> Adding public to the search path is fine by me. However, I still need to find
> out how this situation arose. Is it something I did or something that the
> installer does by default? The project notes 'suggest' 'adempiere' as the
> username for access. However they do not use wording to imply that one must
> use it. However, if there is something in the installer that uses 'adempiere'
> regardless of the properties settings then I need to discover this.

well, actually, you can just set the search_path for the role the application logs in with:

alter role <app_role> set search_path = '<schema>, pg_catalog, public';

The next time <app_role> logs in, it should see the freshly set search_path.

When we create an app schema and role set in our databases, we always do this to make sure that the application role always finds its schema. We never had any problems with this.

https://www.postgresql.org/docs/current/ddl-schemas.html#DDL-SCHEMAS-PATH
https://www.postgresql.org/docs/current/sql-alterrole.html

Hope this helps,
Paul

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2020-10-05 17:46:58 Re: UUID generation problem
Previous Message Adrian Klaver 2020-10-05 17:31:36 Re: UUID generation problem