On Jul 22, 2011, at 12:09 PM, Dinesh Bhandary wrote:
> ...but it will be nice to have a strictly read only user who can just see
> data of the assigned objects and nothing else.
Surely you mean data & structure of the assigned objects and no other objects?
--
Scott Ribe
scott_r...@elevated-dev
We had the same problem, and we still do not have an elegant solution,
we have a workaround which I really don't like.
I agree with Juan - it is a limitation. I understand that you can solve
this problem outside of a database, but it will be nice to have a
strictly read only user who can just
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: Friday, July 22, 2011 10:33 AM
To: Juan Cuervo (Quality Telecom); Bob Lunney
Cc: pgsql-admin@postgresql.org
Subject: Re: revoked permissions on table still allows users to see
table's structure
I don't t
"Juan Cuervo (Quality Telecom)"
wrote:
> Imagine you own a software development company,
Not too hard for me. Been there, done that.
> and decides to base the company's product on Postgresql databases.
> Such a company surely dont want to expose his database design to
> its customers, but i
In my opinion, that is precicely what privileges where created for: in
order to restrict what people with database's access can do.
As I see it, it would make a lot of sense to have something like a
'view_design' privilege on database objects.
Imagine you own a software development company, an
I am still not clear. Can you explain what replication_timeout parameter
accomplishes and when ?
Basically I wish my synchronous write transaction to not wait indefinitely when
the synchronous standby servers are not available. But rather a response
returned back to client that write could not
2011/7/22 Fujii Masao :
> On Fri, Jul 22, 2011 at 1:29 AM, A J wrote:
>> Couple of months back, Josh Berkus posted an issue with promotion of the
>> standby in Streaming replication. Subject 'Standby promotion does not work'
>> in the pgsql-hackers forum.
>
> I could not find that thread.
>
>> It
Bob Lunney wrote:
> That is what schemas, permissions and search paths are for.
I don't think those do as much as you're giving them credit for:
test=> set session authorization dee_ny;
SET
test=> \d
List of relations
Schema | Name | Type | Owner
-+--+---+
Juan,
That is what schemas, permissions and search paths are for. You create
multiple schemas, put the tables in the appropriate ones, grant usage
permissions to those users that need access to the schemas and set the search
path to search the schemas for objects. Below is the test case. It
Fujii Masao wrote:
> On Fri, Jul 22, 2011 at 1:29 AM, A J wrote:
>> Couple of months back, Josh Berkus posted an issue with promotion
>> of the standby in Streaming replication. Subject 'Standby
>> promotion does not work' in the pgsql-hackers forum.
>
> I could not find that thread.
http://ar
On Fri, Jul 22, 2011 at 1:29 AM, A J wrote:
> Couple of months back, Josh Berkus posted an issue with promotion of the
> standby in Streaming replication. Subject 'Standby promotion does not work'
> in the pgsql-hackers forum.
I could not find that thread.
> It seemed that during failover, it wa
Hi Scott
Thanks for your answer.
It should be a way to prevent this from normal users who only need
access to a set of tables, a view or even a store procedure. (Maybe a
VIEW_SCHEMA privilege of roles?). View a table's structure should only
be allowed to users who has at least one privilege o
On Fri, Jul 22, 2011 at 5:14 AM, A J wrote:
> On 9.1, Beta3 I set the following on master
> replication_timeout = 10s # in milliseconds; 0 disables
> With no slaves running, I expect a failure in about 10s. But any Insert just
> hangs. Any idea ?
If you set up synchronous replication but th
On Thu, Jul 21, 2011 at 04:36:56PM +0200, Tom Lane wrote:
>
> Almost always, when you get a cascade of error messages, the thing to
> look at is the *first* error, or first few errors. Not the last ones.
>
> In this case I'd guess that a COPY command failed and psql is now trying
> to process th
14 matches
Mail list logo