Skip site navigation (1) Skip section navigation (2)

Suggestion: Implicit permissions on implicitly generated objects

From: Chris Gamache <cgg007(at)yahoo(dot)com>
To: pgadmin-hackers(at)postgresql(dot)org
Subject: Suggestion: Implicit permissions on implicitly generated objects
Date: 2004-04-29 19:46:42
Message-ID: 20040429194642.66777.qmail@web13811.mail.yahoo.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
In the past (PgAdmin II :) ) when a Sequence was created implicitly by the use
of a "serial" column type, the permissions that were applied to the table at
creation time were applied to the sequence. The column definition was changed
to read something like

id int4 NOT NULL DEFAULT nextval('implicitlygenerated_id_seq'::text);

Now it reads: "id serial NOT NULL" which isn't bad, but is not as specific as
the translated column definition. Permissions aren't propagated as they once
were.

It is also required to manually create a primary key constraint... If the same
table create statement was issued using the query tool, the implicit sequence
would be created, a primary key constraint would be created and an index would
be created implicitly as well. One would still have to add proper permissions
to the sequence if anyone other than the owner/superuser wanted to mess with
it.

"We always used to do it that way ... " is not a good enough reason to change
how PgAdmin III behaves. I'm wondering if these behaviors ares intentional, or
if they are potential TODO items. 

CG

 



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

pgadmin-hackers by date

Next:From: Dave PageDate: 2004-04-30 11:41:23
Subject: Re: Suggestion: Implicit permissions on implicitly generated objects
Previous:From: Mark KirkwoodDate: 2004-04-29 09:10:25
Subject: Re: Row counts for large tables cause temporary

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group