Re: Patch: Query favourites

[Andreas Pflug <pgadmin(at)pse-consulting(dot)de>]

Magnus Hagander wrote:

> > > Anyway, it could be rewritten to either not use XML at all, 
> > >      
> > or to not 
> >    
> >
> > > use wxxml (say by linking directly to libxml, which is 
> > >      
> > likely to be on 
> >    
> >
> > > the system already considering how many packages use it). It 
> > >      
> > just makes 
> >    
> >
> > > it easier when you don't have to maintain the code youself.
> > >
> > >
> > >      
> > There must be some XML stuff in std wx, since XRC uses XML, 
> > dunno how reusable that is.
> >    
>
> It specifically says that the API is not stable and should not be used.
> (http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/xml/xml.h?rev
> =1.5&content-type=text/vnd.viewcvs-markup and friends)
>
>
>
>  
>
> > > As for the fact that you can already store them in standard files - 
> > > sure you can. It's a matter of convenience.
> > >
> > >      
> > Still appears as a duplication of features. What's wrong with 
> > "recent files"?
> >    
>
> No hierarchy, very very limited number of entries, no control over which
> entries go on the list (say when you open a one-time file to run, it
> will still steal a position on the list), no ability to add descriptive
> entries. I'm sure there are more, but that's what I came up with whlie
> typing without needing to think about it.
>
>
>  
>
> > Actually, I'd like it better to have a means of adding 
> > macros/scripts or so to pgAdmin, i.e. wxPython. This would 
> > enable pgAdmin extensions, keeping the pgAdmin core relatively pure.
> >    
>
> Sure, that'd be nice. Still, that adds a dependency on *python*, which
> is *huge* compared to wxxml... 
>  
I don't mind adding dependencies if benefits are huge (last addition was 
OGL for graphical explain, which is a std wx contrib module). The few 
preferred queries I'm using are in some files, and I simply mark and 
execute them. That's why I can't see any benefit from such a "favourite" 
feature.


> And I don't see the point in this case. 
The point is, the scripting option I'm thinking of would allow you to 
declare your own menu entry for your preferred query (which might 
consist of a dialogue, formatting your result) so it's not the query 
you're storing, but but the feature/task/whatever. Just as we have a 
status display, not just a favourite "select * from pg_status".

Regards,
Andreas