Re: extending functionality strategy
От | Dave Page |
---|---|
Тема | Re: extending functionality strategy |
Дата | |
Msg-id | 937d27e10810162214y17e69ce7icf6f66f8d3db76e2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: extending functionality strategy ("Gevik Babakhani" <pgdev@xs4all.nl>) |
Ответы |
Re: extending functionality strategy
|
Список | pgadmin-hackers |
On Thu, Oct 16, 2008 at 9:22 AM, Gevik Babakhani <pgdev@xs4all.nl> wrote: >> Can you describe this in more detail? We can already manage > > It was late last night. I will try to explain it better. > >> and create types in pgAdmin (albeit our support for complex >> types requiring an initial 'shell' type is somewhat lacking). > > I was playing with GQD and got this idea to have a similar functionality > except instead of generating a SELECT statement, to generate a CREATE TYPE > .... > > Looking at the current type creator: > > 1) Perhaps it could be extended with an additional tab where one is able to > click and select table columns. To use as a template? That's not really functionality for the straightforward properties dialogue though. > 2) Like the GQD add column ordering to the Definition tab for rearranging. For consistency, we'd have to add similar buttons to a whole bunch of other places. > 3) I haven't given this much thought but yet another idea is to create a > type based on a SELECT statement. (have something similar in C#) Most of what you propose would not be implemented in the type dialogue itself, but would be something for a wizard - but I don't think there are enough people who actually create types in pgAdmin to justify the effort - espcially as once we create oe wizard such as this, it pretty much implies we will have to create others as we move forward. Now if you implemented it as a Python based plugin, that would perhaps be a different matter (but would of course, require the plugin architecture to be built!) -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
В списке pgadmin-hackers по дате отправления: