Re: [FEATURE] Add schema option to all relevant objects - Mailing list pgadmin-hackers

From Thom Brown
Subject Re: [FEATURE] Add schema option to all relevant objects
Date
Msg-id CAA-aLv7tPb=S+OQR_CKBJKByuyc0ofQCXTuvuCtsqKSEPyAZ4A@mail.gmail.com
Whole thread Raw
In response to Re: [FEATURE] Add schema option to all relevant objects  (Dave Page <dpage@pgadmin.org>)
Responses Re: [FEATURE] Add schema option to all relevant objects  (Dave Page <dpage@pgadmin.org>)
List 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 by date:

Previous
From: Dave Page
Date:
Subject: Re: [FEATURE] Add schema option to all relevant objects
Next
From: Dave Page
Date:
Subject: Re: [FEATURE] Add schema option to all relevant objects