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

Re: Table modification

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: "'Jean-Michel POURE'" <jm(dot)poure(at)freesurf(dot)fr>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Table modification
Date: 2001-10-02 09:06:57
Message-ID: AA30E7BCCA5C1D4E88A231900F8325C00B53@dogbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm(dot)poure(at)freesurf(dot)fr] 
> Sent: 02 October 2001 09:41
> To: pgadmin-hackers(at)postgresql(dot)org
> Subject: [pgadmin-hackers] Table modification
>
> Dave, could we please again discuss about the table 
> modification feature? I understand we have three alternatives:
> 
> 1) Implement table rebuilding in frmTable at pgAdmin II level 
> Easy way, but pgSchema users will not benefit from it. Can be 
> done easily and quickly.

No. Not acceptable. pgAdmin does not know about SQL. That's pgSchema's job.
If pgAdmin starts creating or modifying objects, then the pgSchema object
model will become out of sync and the revision control auto commit will fail
- yes, Revision Control is now in CVS :-) though only the logging/status
tracking at present. History Viewing/Rollback should be there soon.

> 2) Implement partial table rebuilding at pgSchema level 
> frmTable would just have to 
> svr.Databases(ctx.CurrentDB).Tables(objTable.Identifier).Colum
> ns.Remove($COL
> NAME). pgSchema would handle the rest. The problem is that we 
> might need a 
> CREATE TABLE AS for each item we
> remove in a table (column, foreign key, etc..). This works for small 
> tables, not the large ones I have.

This is the correct way to do it, though I appreciate your problem with
large tables. Perhaps (for Table objects only) we should have a
Tables.DeferRebuild property. When set true, all rebuilds triggered by mods
of individual properties or collections will get queued up until an update
method is fired. That way, the update method can reduce all the required
rebuilds that are queued up into as small an operation as possible.

What do you think?

> Do I miss something?

I don't think so. I would suggest that we both sleep on how to achieve the
above for a while - in the meantime look at the more simple mods like
updating functions/views/triggers.

BTW, any object modifications in pgSchema should be followed by a call to
Commit (see the existing comment properties) eg:

If Not SystemObject Then Commit rcUpdate, "Updated object comment."

Regards, Dave.

pgadmin-hackers by date

Next:From: Jean-Michel POUREDate: 2001-10-02 09:41:08
Subject: Re: Table modification
Previous:From: Jean-Michel POUREDate: 2001-10-02 08:41:04
Subject: Table modification

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