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

Re: Suggestion: Implicit permissions on implicitly generated objects

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: <cgg007(at)yahoo(dot)com>, <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Suggestion: Implicit permissions on implicitly generated objects
Date: 2004-04-30 14:55:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers

> -----Original Message-----
> From: Chris Gamache [mailto:cgg007(at)yahoo(dot)com] 
> Sent: 30 April 2004 14:46
> To: Dave Page; pgadmin-hackers(at)postgresql(dot)org
> Subject: RE: [pgadmin-hackers] Suggestion: Implicit 
> permissions on implicitly generated objects 
> --- Dave Page <dpage(at)vale-housing(dot)co(dot)uk> wrote:
> > Both pgAdmin II and III create serial columns in the same 
> way - ie. by 
> > executing a query like 'CREATE TABLE foo (bar serial);'. 
> pgAdmin III 
> > will reverse engineer the SQL a little more intelligently 
> though - if 
> > the default value matches "nextval('<schema>.<table>_<column>_seq')"
> > then it automatically rewrites the default into a 'serial' column.
> Since PostgreSQL 7.3+ creates a dependency for sequences such 
> that if a table is dropped the sequence is dropped as well, 
> then the table (re)creation would require vartype "serial" 
> for the implicit generation of the required sequence.
> Is that a good shot at the reason for the change? My only 
> cause for concern is that I have to guess at the sequence 
> name, based on table name. If the table name changes (which 
> sometimes has to happen), the sequence name will not change 
> to match. Would you consider placing the sequence name in a 
> "--" comment on the same or subsequent line?

The main reason for this is to hide the implementation details. 99% of
users don't care how a serial column works, merely that it does.

> > pgAdmin never propagated permissions.
> Please accept my apologies. They say the second thing to go 
> is the memory... :) Wouldn't it be nice if PgAdmin III did 
> propagate permissions for implicitly created objects? (Unless 
> you can think of a reason that it wouldn't make sense to do 
> such a thing...)

I think that is the job of the server to be honest.

> I'll try to do better:
> There's a simple checkbox to make a column a primary key in 
> PgAdmin II. There's a more complicated procedure to create a 
> primary key in PgAdmin III within the constraint tab. I 
> understand that "We always used to do it that way ... " is 
> not a good reason to keep something the same. I guess I can 
> see how putting all of your constraints together in one tab 
> is more logical than a checkbox and two tabs (a la PgAdmin 
> II). Was that what you were going for? ... 

Andreas refactored that bit, but I guess there are 2 main reasons -
first, it's more logical as you suggest, and secondly, the coding is a
lot more elegant.

> As I study it more, I can see how the tool flows. Since the 
> tabs are meant to build one-to-the-next, perhaps instead of 
> an "OK" at the bottom of the window, a "Next" might be just 
> as good. Since "Primary Key" now lives in the Constraint Tab, 
> I'll have to visit every tab anyway.  When you get to the SQL 
> Def you can verify that the SQL reflects what you want done, 
> and then you can click "OK" or "Back" or a specific tab to 
> make changes. You could apply that methodology to all of the 
> New Object Dialog Boxes. What do you think?

That would make them wizards rather than dialogues. I'm not against
having wizards as well, but I don't think we should have a Next button
to iterate through tabs (pga2 did in some places, but that was for
technical reasons and you couldn't click those tabs anyway) - Crystal
Reports does that and it's just plain /wrong/ :-)

Regards, Dave.

pgadmin-hackers by date

Next:From: Mark KirkwoodDate: 2004-05-01 04:08:00
Subject: CVS Build on FreeBSD 4.9
Previous:From: Chris GamacheDate: 2004-04-30 13:46:11
Subject: Re: Suggestion: Implicit permissions on implicitly generated objects

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