Re: Suggestion: Implicit permissions on implicitly generated objects - Mailing list pgadmin-hackers

> -----Original Message-----
> From: Chris Gamache [mailto:cgg007@yahoo.com]
> Sent: 30 April 2004 14:46
> To: Dave Page; pgadmin-hackers@postgresql.org
> Subject: RE: [pgadmin-hackers] Suggestion: Implicit
> permissions on implicitly generated objects
>
> --- Dave Page <dpage@vale-housing.co.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.