I'd really love the ability to grant a *user*
role-based privileges database by database.
For background, I have several databases running
in a single cluster, one database per business unit.
Each database has the same core schema with the same
basic role permissions, but with significant
cu
On Wed, May 29, 2013, at 04:26 AM, Albe Laurenz wrote:
> Clark C. Evans wrote:
> > I'd really love the ability to grant a *user*
> > role-based privileges database by database.
>
> The only cluster-wide role permissions are the options
> SUPERUSER, CREATEDB, CREA
On Wed, May 29, 2013, at 09:45 AM, Stephen Frost wrote:
> * Albe Laurenz (laurenz.a...@wien.gv.at) wrote:
> > Maybe the db_user_namespace parameter can help:
> > http://www.postgresql.org/docs/9.2/static/runtime-config-connection.html#GUC-DB-USER-NAMESPACE
>
> I doubt it and I wouldn't encourage a
On Wed, May 29, 2013, at 10:08 AM, Stephen Frost wrote:
> This capability might well come with a real way to have per-database
> roles in general, which has been asked for quite often as well. You
> would then be able to have an 'auditor' role in each database and have
> them actually be different
On Sat, 13 Nov 2010 17:23 +0200, "Marko Tiikkaja" wrote:
> So these queries would behave differently?
>
> WITH t AS (DELETE FROM foo RETURNING *)
> SELECT 1 WHERE false;
>
> WITH t AS (DELETE FROM foo RETURNING *)
> SELECT 1 FROM t LIMIT 0;
I'm still trying to wrap my head around this
new mechani
On Monday, September 19, 2011 9:20 AM, "David Fetter"
wrote:
> On Mon, Sep 19, 2011 at 10:58:49AM -0400, Joe Abbate wrote:
> > On 09/19/2011 09:50 AM, Josh Berkus wrote:
> > > FWIW, the fact that the drafts *are* confidential is symptomatic
> > > of everything which is wrong with the ISO.
> >
> >
On Mon, Sep 30, 2002 at 06:49:34PM -0400, Tom Lane wrote:
| The other issue is what
| to_date(...,'WW') should do to produce a date representing a week
| number. Shouldn't it always produce the first date of that week?
| If not, what other conventions make sense?
IMHO, it should choose the "
or less of the
user base...
Best,
Clark
--
Clark C. Evans Axista, Inc.
http://www.axista.com800.926.5525
XCOLLA Collaborative Project Management Software
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Sorry to ressurect this thread. However, I've been playing with the new
role system and I'd prefer to keep CURRENT_USER as the login user, and
not making it a synonymn for CURRENT_ROLE. In my application, I love the
ability to "shed" privleges by "SET ROLE dataentry;". However, I need
CURRENT_US
It would be wonderful to be able to create comments
on users and groups. In particular, I need a place
to store the user's name. Yes, I could make a user
table, but that seems overkill as all of the other
aspects of a user are already in the metadata.
Best,
Clark
--
Clark C.
Hello all. I've got a question with regard to the INFORMATION_SCHEMA
of PostgreSQL, specificially related to constraints. In the SQL92
specification, the DEFINITION_SCHEMA.DOMAIN_CONSTRAINTS (the "imaginary"
base for INFORMATION_SCHEMA.DOMAIN_CONSTRAINTS), has a primary key:
CONSTRAINT_CATALOG,
On Fri, Feb 24, 2006 at 04:23:19PM -0800, Josh Berkus wrote:
| Correct. Our uniqueness on constraints is:
| schema_name | table_name | constraint_name
|
| We're aware that it's a violation of SQL92, but there's no way for us to
| change it now without making it very hard for people to upgrade.
On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
| > This has been discussed previously in a couple of threads. I believe the
| > desire is to make it work as specified in SQL-2003, but I do not remember
| > whether or not anyone volunteered to do the work to make it happen.
|
| I beli
On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
| > > * for foreign-key and check constraints, the default names
| > > are $1, $2, etc.; it would be great if they were "upgraded"
| > > to use the default names given by primary and unique key
| > > constraints: table_uk
d
| k=# insert into a values ('bar', 'foo');
| INSERT 0 1
and this insert should fail. The opposite happens beacuse PostgreSQL
is storing _more_ information than what is specified and has over
interpreted the meaning of the reference clause.
On Sat, Feb 25, 2006 at 02:01:00P
Stephen,
So, a quick re-cap of the questions/concerns I had:
* Making the default constraint names include the table
-> This was implemented in 8.x, thank you!
* Forbidding the creation of a foreign key constraint where
the column list for the referenced table doesn't *exactly*
On Sat, Feb 25, 2006 at 10:52:48PM -0800, Stephan Szabo wrote:
| > * Forbidding the creation of a foreign key constraint where
| > the column list for the referenced table doesn't *exactly*
| > match a canidate key on that table.
|
| About the best we're likely to be able to do is change
On Mon, Feb 27, 2006 at 11:39:30AM -0500, Tom Lane wrote:
| Josh Berkus writes:
| >> No way. The entire point of information_schema is that it is standard;
| >> adding non-spec things to it renders it no better than direct access
| >> to the PG catalogs.
| >
| > Hmmm ... so, per you, we can't add
On Tue, Mar 14, 2006 at 08:14:12PM -0800, Stephan Szabo wrote:
| > CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
| > CREATE TABLE a (b text, c text);
| > ALTER TABLE a ADD FOREIGN KEY (b, c) REFERENCES x(z, y);
...
| > I assert the problem here is that the FOREIGN KEY constraint
|
On Tue, Mar 14, 2006 at 10:01:16PM -0800, Stephan Szabo wrote:
| The point is that because rows in a table don't have order (unless
| information_schema has special rules) the two constraints above seem to
| look the same to me in their representation in
| information_schema.constraint_column_usage
On Tue, Mar 14, 2006 at 11:11:29PM -0800, Stephan Szabo wrote:
| When we're allowing other order access, immediately reorder the
| constraint information to match the primary key order.
Let me try to parrot. In PostgreSQL, the pairing information between
the foreign-key and unique-key constraint
21 matches
Mail list logo
