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

On Tue, 2011-07-05 at 21:01 +0100, Thom Brown wrote:
> On 5 July 2011 20:47, Guillaume Lelarge <guillaume@lelarge.info> wrote:
> > Hi Thom,
> >
> > On Tue, 2011-07-05 at 20:23 +0100, Thom Brown wrote:
> >> [...]
> >> I noticed that objects which can be moved to different schemas can't
> >> be moved in PgAdmin, so I looked to see if there was any request to
> >> have this implemented, and found this ticket:
> >> http://code.pgadmin.org/trac/ticket/5
> >>
> >
> > Exactly. I did a complete patch once, but my main issue, that I couldn't
> > fix, was the refresh of the schemas in the browser.
> >
> >> So I have now implemented this.  A schema drop-down box will appear in
> >> the properties dialogue for each relevant object beneath the owner
> >> drop-down.
> >
> > Did you fix the issue with the refresh of the browser? (I can't check
> > yet, I'm doing a last time compile of Jasmin's patch :) )
>
> I got it refreshing the node in the original schema, but not the
> destination one.
>

Which is an issue. People may understand that pgadmin doesn't know about
new or altered objects if the object is created or changed outside of
the UI. But inside the UI, it should refresh its browser.

> >>   I noticed that the Extensions properties dialogue already
> >> had one in it (and I've changed how it works),
> >
> > Oops, that was probably a bad move. Extensions don't have schemas by
> > themselves. Their objects have one, but not the extension in itself.
> > (Once again, I may be wrong as I didn't read your patch yet)
>
> Well from reading the docs, it suggested the extension itself resided
> within a schema, but maybe you're right.
>

Not the extension, but the objects it owns.

> >>  but left it where it
> >> was.  In order to implement these changes, I had to also fix quite a
> >> few bugs, and while I was at it, implemented a few additional changes.
> >>  They are as follows:
> >>
> >> - Prevent functions having a complete rewrite when changing owner
> >> - Add the ability to specify an owner for operators at creation time
> >> - Fix invalid syntax on text search configuration, parser and template
> >> when modifying the name
> >> - Fix unescaped name when modifying text search configuration, parser
> >> and template name
> >> - Disabled the owner field on text search dictionaries as it cannot be modified
> >> - Allow renaming types for versions 8.4 and higher
> >>
> >
> > You're gonna hate me, but can you extract the fixes, one by one, from
> > the actual new feature? even if we won't apply all of them to 1.14, I
> > don't want to mix them with the real new feature (at least for
> > pgAdmin :) ).
>
> Hmmm... okay, I'll look at doing that.
>

Thanks.

> >> I also refactored some code, including re-basing the extensions class
> >> on the pgSchema class rather than pgDatabase
> >
> > Bad move once again. An extension doesn't have a schema.
> >
> >> , replace explicit SET
> >> OWNER clauses with common function
> >
> > Can you explain that one?
>
> Rather than building up the ALTER <object> SET OWNER in each class, I
> made them all use the AppendOwnerChange function
>

Oh, great. Thanks.

> >>  and tore out a few things from the
> >> text search classes which were just causing problems rather than
> >> helping.
> >>
> >
> > More explanations please?
>
> The GetQuoteIdentifier functions these class headers implemented (e.g.
> include/schema/pgTextSearchConfiguration.h) didn't quote the name from
> what I recall, so ended up deleting them, and they just inherit the
> same function from its base class.
>

OK, good thing too.

> >> Cheers!
> >>
> >
> > Thanks a lot for your work. This patch was something I was waiting for.
> >
> > BTW, are you going to char(11)?
>
> Unfortunately no. :(
>

Too bad. I owe you a beer next time.


--
Guillaume
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com