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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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.

Browse pgadmin-hackers by date

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