Re: [FEATURE] Add schema option to all relevant objects
От | Dave Page |
---|---|
Тема | Re: [FEATURE] Add schema option to all relevant objects |
Дата | |
Msg-id | CA+OCxow2eAFyMTkxS66s2bfqKu3e6TNygyHZYyP=4F3YLaZtRg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [FEATURE] Add schema option to all relevant objects (Thom Brown <thom@linux.com>) |
Список | pgadmin-hackers |
On Friday, July 8, 2011, Thom Brown <thom@linux.com> wrote: > 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. Think of an extension as 2 things - the packaging, and the contents. The packaging is what we show under the Database node - it doesn't have a schema. The contents do have a schema, and the packaging mechanism gives you a simple way to change it. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgadmin-hackers по дате отправления: