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: | 03AF4E498C591348A42FC93DEA9661B889FC00@mail.vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2004-05-01 04:08:00 | CVS Build on FreeBSD 4.9 |
Previous Message | Chris Gamache | 2004-04-30 13:46:11 | Re: Suggestion: Implicit permissions on implicitly generated objects |