On 9/6/16 3:16 PM, Greg Fodor wrote:
It seems that functionality that lets a superuser quickly audit the
privileges for a user (including those granted via PUBLIC) would be
really helpful for diagnosing cases where that user can do something
they shouldn't be allowed to.
That's actually relativ
Stephen Frost writes:
> \dn+ in psql will give you the access privileges for all schemas.
> I'd have to look at the "other solutions" you're referring to, but, in
> general, we do not exclude the public role in any way from the access
> privilege system.
Possibly Greg was thinking of the informa
Gregm
* Greg Fodor (gfo...@gmail.com) wrote:
> A, I wasn't aware of the PUBLIC meta-role. Not sure if it's useful
> feedback, I spent a lot of time digging around the web for solutions
> that would basically let me query the database to see all of the
> effective privileges for a user, and non
A, I wasn't aware of the PUBLIC meta-role. Not sure if it's useful
feedback, I spent a lot of time digging around the web for solutions
that would basically let me query the database to see all of the
effective privileges for a user, and none of the solutions I found
were able to get me to a po
Greg Fodor writes:
> Apologies in advance about this since it is likely something obvious,
> but I am seeing some very basic behavior that does not make sense.
> I've tested this on a fresh build of 9.6rc1 and also 9.1.24 (just to
> see if it was a regression.) After creating a test database, and
Greg,
* Greg Fodor (gfo...@gmail.com) wrote:
> Apologies in advance about this since it is likely something obvious,
> but I am seeing some very basic behavior that does not make sense.
> I've tested this on a fresh build of 9.6rc1 and also 9.1.24 (just to
> see if it was a regression.) After crea
Bryan Ellerbrock writes:
> Huh. Thanks for the quick reply Joe. I'm still not sure I fully understand
> the behavior here, but it's nice to at least be able to discuss it.
>
> The documentation you shared makes it clear that, unless extra steps
> are taken, changes to an extension's object defin
On 02/26/2016 07:12 AM, David G. Johnston wrote:
> pg_dump emits a "CREATE EXTENSION" statement to the dump file and then
> pg_restore executes the "CREATE EXTENSION". None of the actual schema
> objects are dumped and thus any changes to those objects in the current
> database, including their pe
On Fri, Feb 26, 2016 at 8:00 AM, Bryan Ellerbrock wrote:
> Huh. Thanks for the quick reply Joe. I'm still not sure I fully understand
> the behavior here, but it's nice to at least be able to discuss it.
>
> The documentation you shared makes it clear that, unless extra steps are
> taken, changes
Huh. Thanks for the quick reply Joe. I'm still not sure I fully understand
the behavior here, but it's nice to at least be able to discuss it.
The documentation you shared makes it clear that, unless extra steps are
taken, changes to an extension's object definitions won't be preserved in a
dump.
On 02/25/2016 03:42 PM, Bryan Ellerbrock wrote:
> Hi, I'm first time mailing-list user with a problem. I'm working on a
> UTF8 encoded database using psql (9.5.1, server 9.4.6)
>
> I've implemented a very large materialized view to speed up certain
> search queries. I need to give users the abilit
On 2011-01-21 16.16, Andy Colson wrote:
On 1/20/2011 11:56 PM, Adarsh Sharma wrote:
Dear all,
I want to know ACl of different users on different tables and databases
in Postgresql.
Is there any command as we do in mysql as :
select * from mysql.user\G;
I am researching but cannot able to fi
On 1/20/2011 11:56 PM, Adarsh Sharma wrote:
Dear all,
I want to know ACl of different users on different tables and databases
in Postgresql.
Is there any command as we do in mysql as :
select * from mysql.user\G;
I am researching but cannot able to find.
Thanks & Regards
Adarsh Sharma
u
"Christian Rengstl" <[EMAIL PROTECTED]> writes:
> whenever I execute the following query as admin I get all results, but
> as soon as I execute it as a less-privileged user the result is empty.
> SELECT * FROM information_schema.schemata
The SQL standard specifies that information_schema.schemata
On Sat, Jul 23, 2005 at 06:43:20PM -0500, Peter Fein wrote:
> I suppose this issue will go away when autovacuum is integrated into the
> server itself in 8.1?
Yes, it already did.
--
Alvaro Herrera ()
"Hoy es el primer día del resto de mi vida"
---(end of broadcast)
Peter Fein wrote:
> I've password protected the 'postgres' account (to enable secure remote
> access) and I don't want to store the password on the local file system.
> I therefore want to create a separate account for use by pg_autovacuum
> (locked down in pg_hba.conf and perhaps with a password).
James --
I am not sure if anyone answered this yet, but you might try:
GRANT USAGE ON SCHEMA sma_apps TO sma_user;
as the same user as createdthe schema ...
HTH,
Greg Williamson
DBA
GlobeXplorer LLC
-Original Message-
From: James Moe [mailto:[EMAIL PROTECTED]
Sent: Mon 2/14/2005 10:
On Mon, Feb 14, 2005 at 11:59:33AM -0700, James Moe wrote:
>
> When logged in as sma_user, it is denied access to the schema:
> ERROR: permission denied for schema sma_apps
See "Schemas and Privileges" in the documentation, as well as the
documentation for GRANT:
http://www.postgresql.org/docs/8
On Sun, 24 May 1998, The Hermit Hacker wrote:
> That command did not return an error, rather it said CHANGE (without
> the exclamation marks, of course). However, afterward, I was still able
> to insert into the table. What gives?
It works for me, I have v6.3
>
> Also, another question:
>
Besides \z ?
The Hermit Hacker wrote:
> Hello all,
>
> I have a couple of questions for you:
>
> We are trying to setup a "group" in our database... groupx.
> I found the syntax in the FAQ, from the PostgreSQL homepage.
> So, we followed the syntax and created the group:
>
> insert into pg_group
20 matches
Mail list logo
