Skip site navigation (1) Skip section navigation (2)

Re: Patch: Query favourites

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>
Cc: <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Patch: Query favourites
Date: 2006-01-29 20:55:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
> >>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.

On this we clearly disagree (on the value of the feature, that is). But
that's your choice, of course. I'll keep running with it myself until
such a time as an alternative exists.
Let's, as they say, agree to disagree on it.

> >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".

Oh, ok. Then I see what you mean. I still don't see it as a clear
replacement, but it would certainly a good feature.


pgadmin-hackers by date

Next:From: Nicholas ThieleDate: 2006-01-30 01:55:23
Subject: Sorting and filtering in PgAdmin
Previous:From: Andreas PflugDate: 2006-01-29 19:43:19
Subject: Re: Patch: Query favourites

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group