Re: Pseudo table modification - Mailing list pgadmin-hackers

From Dave Page
Subject Re: Pseudo table modification
Date
Msg-id AA30E7BCCA5C1D4E88A231900F8325C00B23@dogbert.vale-housing.co.uk
Whole thread Raw
In response to Pseudo table modification  (Jean-Michel POURE <jm.poure@freesurf.fr>)
List pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: 25 September 2001 20:59
> To: pgadmin-hackers@postgresql.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:

Previous
From: Jean-Michel POURE
Date:
Subject: Pseudo table modification
Next
From: Jean-Michel POURE
Date:
Subject: UNICODE information