Re: Pseudo table modification
От | Dave Page |
---|---|
Тема | Re: Pseudo table modification |
Дата | |
Msg-id | AA30E7BCCA5C1D4E88A231900F8325C00B23@dogbert.vale-housing.co.uk обсуждение исходный текст |
Ответ на | Pseudo table modification (Jean-Michel POURE <jm.poure@freesurf.fr>) |
Список | 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 по дате отправления: