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 по дате отправления:

Предыдущее
От: Jean-Michel POURE
Дата:
Сообщение: Pseudo table modification
Следующее
От: Jean-Michel POURE
Дата:
Сообщение: UNICODE information