Re: 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?

> 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...)

>
> > 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.
>
> Sorry, you've lost me there.

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? ...

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?

CG




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