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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgadmin-hackers by date

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