Re: Upgraded, now permission denied.
От | Jason Whitener |
---|---|
Тема | Re: Upgraded, now permission denied. |
Дата | |
Msg-id | CAP78pDL3ocN9-4S9-4W5nvtjBtEnAA_2JcmYUWQgfgYeP6eZeg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Upgraded, now permission denied. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-novice |
That worked, thank you.
mypcc=# GRANT ALL ON SCHEMA PUBLIC TO PUBLIC;
GRANT
mypcc=# \q
-bash-4.1$ psql mypcc mypcc
psql (8.4.20)
Type "help" for help.
mypcc=> select * from uiddate where dateonline >= '2014-06-11';
uid | dateonline | uiddateonline | server
-----+------------+---------------+--------
(0 rows)
Now to do some more reading about schemas and roles. Thanks again.
On Thu, Jun 12, 2014 at 5:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jason Whitener <jwhitene@pcc.edu> writes:Ah-hah, as I rather suspected: public access to the "public" schema has
>> Well, that's what I'd expect to see --- but the prompt indicates that you
>> did this in the "postgres" database, which is not where you're having the
>> problem. We need to look at the public schema within the mypcc database.
> Oops. Here's the mypcc database.
> psql mypcc mypcc
> mypcc=> select * from pg_namespace where nspname = 'public';
> nspname | nspowner | nspacl
> ---------+----------+------------------------
> public | 10 | {postgres=UC/postgres}
> (1 row)
been revoked. (There's some info in the GRANT man page about reading
ACL displays, if you're not sure how to interpret the above.)The reason for these odd behaviors is that unreadable schemas get dropped
> mypcc=> \dt
> No relations found.
out of your search_path (rather than throwing errors). So the tables are
there, but unless you're superuser you can't get at them.
I'd suggest a "GRANT ALL ON SCHEMA PUBLIC TO PUBLIC".
It's still unclear how you got those permissions revoked, but it seems
pretty clear that you didn't really want to do that.
regards, tom lane
В списке pgsql-novice по дате отправления: