Re: [FEATURE] Add schema option to all relevant objects
От | Thom Brown |
---|---|
Тема | Re: [FEATURE] Add schema option to all relevant objects |
Дата | |
Msg-id | CAA-aLv7tPb=S+OQR_CKBJKByuyc0ofQCXTuvuCtsqKSEPyAZ4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [FEATURE] Add schema option to all relevant objects (Dave Page <dpage@pgadmin.org>) |
Ответы |
Re: [FEATURE] Add schema option to all relevant objects
|
Список | pgadmin-hackers |
On 8 July 2011 20:15, Dave Page <dpage@pgadmin.org> wrote: >>> * all extension changes are wrong according to me because they aren't >>> schema objects, but database objects. I don't keep them. >> >> The reason why I based it on schema is because I wanted it to inherit >> the schema combobox object and its source for a list of schemas so >> lots of redundant code could be removed. There should be no >> functional difference, but I'm probably missing the point here. :) > > It's a misuse of the class, because it's intended to represent the > schema the object is in, not one it's related to in some other way. > We've made the mistake of trying to use these classes in ways that > weren't intended in the past, and it's bitten us badly. I'm not keen > to repeat that, for the sake of a few lines of code to store a schema > name, Whilst I don't see the actual impact, I'll concede the point since I've only just started looking at code really so wouldn't have seen the issue first-hand. Extensions are a weird case for me since you can assign them to a schema, but they are immune to being hidden by the search path. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgadmin-hackers по дате отправления: