From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | byrnejb(at)harte-lyne(dot)ca |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: UUID generation problem |
Date: | 2020-10-03 01:13:07 |
Message-ID: | 1314954.1601687587@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"James B. Byrne" <byrnejb(at)harte-lyne(dot)ca> writes:
> On Fri, October 2, 2020 18:46, Tom Lane wrote:
>> The two likely possibilities are that Idempiere isn't connecting to the
>> same database as you are doing manually, or that it is using a search_path
>> setting that doesn't include the "public" schema.
>> I think you could also get this if the "public" schema is not readable
>> by Idempiere's userid, but that doesn't seem terribly likely.
> idempiere=# \dn
> List of schemas
> Name | Owner
> -----------+-----------
> adempiere | adempiere
> public | postgres
Uh ... that rules out exactly none of those three possibilities.
"\dn" says what schemas exist, but it tells you nothing about
either search_path or privileges.
You could try "select current_schemas(true)" to narrow things
down a little bit, as that would show the active search path
in your session.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | James B. Byrne | 2020-10-03 02:17:27 | Re: UUID generation problem |
Previous Message | Adrian Klaver | 2020-10-03 00:17:11 | Re: UUID generation problem |