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

Re: Pseudo table modification

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Pseudo table modification
Date: 2001-09-25 20:22:56
Message-ID: AA30E7BCCA5C1D4E88A231900F8325C00B23@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: 25 September 2001 20:59
> To: pgadmin-hackers(at)postgresql(dot)org
> Subject: [pgadmin-hackers] Pseudo table modification
> 
> 
> Hi,
> 
> This is about pseudo table modification in pgAdmin II.
> 
> Does it make sense to implement it at pgSchema level (I know 
> it can be done 
> at pgAdmin level) ?
> 
> Tables.cls
> Public Function Modify (ByVal Name As String, ByVal Columns 
> As String, 
> Optional ByVal PrimaryKeys As String, Optional ByVal Checks 
> As String, 
> Optional ByVal ForeignKeys As String, Optional ByVal Inherits 
> As String, 
> Optional ByVal Comment As String) As pgTable
> We have to look for existing triggers
> 
> More difficult job but better design in the future ?

No, this is not the way to do it. Look at the pgTable.cls Name property,
both the Get and Let are public, so the name can be changed by Let... An
Internal (iName) is declared as a Friend and is used to populate the class.
In the perfect world, *all* properties would be Public Let & Get with an
additional Friend Let for initial population.

In the case of Columns/Fkeys etc (ie. Complete objects in themselves), we
can add Add and Remove methods to the collection classes.

Regards, Dave.

pgadmin-hackers by date

Next:From: Jean-Michel POUREDate: 2001-09-26 10:24:11
Subject: UNICODE information
Previous:From: Jean-Michel POUREDate: 2001-09-25 19:59:16
Subject: Pseudo table modification

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