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, CREATEROLE, INHERIT,
LOGIN and REPLICATION
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 anyone
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
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
On Monday, September 19, 2011 9:20 AM, David Fetter da...@fetter.org
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 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 mechanism.
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_USER
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
|
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
On Mon, Feb 27, 2006 at 11:39:30AM -0500, Tom Lane wrote:
| Josh Berkus josh@agliodbs.com 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
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 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
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_1stcol,
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:00PM -0800, Stephan Szabo wrote:
| On Sat, 25 Feb 2006, Clark C. Evans wrote:
|
| CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
| CREATE
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*
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.
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. Evans
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
--
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]
21 matches
Mail list logo
