Обсуждение: PGADMIN3 request for preferences-related behavior change

Поиск
Список
Период
Сортировка

PGADMIN3 request for preferences-related behavior change

От
John Genoese
Дата:
Greetings, and thanks for a truly great product!

There's one thing that would make my life easier: the ability to save discrete PGADMIN3 preference files for discrete PGADMIN3 instances under the same user. Failing that, can we at least have the ability for the preferences file to have support for multiple versions/instances of PGADMIN3 (like Version-sensitive sections, or some such)?

I'm using Mac OS X (10.7) and my client base requires me to maintain both 8.4 and 9.1.3. On a Mac, this doesn't present any problem at all, because you guys did such a great packaging job. A thousand thanks for that, truly!

But what does present a problem is PGADMIN3. I have to manually change preferences each time I change versions, because the 1.12 pgadmin3 and the 1.14 pgadmin3 use the same physical file ( ~/Library/Preferences/pgadmin3 Preferences). I even tried to hack around using symbolic links, but PGADMIN3 writes back the properties file on exit, obliterating my symbolic link. Ouch! So there's really no way I can conveniently deploy multiple instances of PGADMIN3 without a great deal of hassle. If there's a way to do this that already exists (and I have looked, believe me) then I'm sorry, and you could point me to the doc and tell me to RTFM. 

Anyway, thanks for taking the time to read this, and thanks again for your great efforts! Well done!

John J. Genoese * Chief Technology Servant * Memories, Dreams, and Reflections LLC

Re: PGADMIN3 request for preferences-related behavior change

От
Guillaume Lelarge
Дата:
On Fri, 2012-03-23 at 15:21 -0400, John Genoese wrote:
> Greetings, and thanks for a truly great product!
>
> There's one thing that would make my life easier: the ability to save discrete PGADMIN3 preference files for discrete
PGADMIN3instances under the same user. Failing that, can we at least have the ability for the preferences file to have
supportfor multiple versions/instances of PGADMIN3 (like Version-sensitive sections, or some such)? 
>
> I'm using Mac OS X (10.7) and my client base requires me to maintain both 8.4 and 9.1.3. On a Mac, this doesn't
presentany problem at all, because you guys did such a great packaging job. A thousand thanks for that, truly! 
>
> But what does present a problem is PGADMIN3. I have to manually change preferences each time I change versions,
becausethe 1.12 pgadmin3 and the 1.14 pgadmin3 use the same physical file ( ~/Library/Preferences/pgadmin3
Preferences).I even tried to hack around using symbolic links, but PGADMIN3 writes back the properties file on exit,
obliteratingmy symbolic link. Ouch! So there's really no way I can conveniently deploy multiple instances of PGADMIN3
withouta great deal of hassle. If there's a way to do this that already exists (and I have looked, believe me) then I'm
sorry,and you could point me to the doc and tell me to RTFM.  
>

I'm not sure I understand why you would like to use 1.12 and 1.14
releases. You can use 1.14 with 8.4 and 9.1.

The only reason I can imagine is that you want different bin directories
for pg_dump and pg_restore. Is that it?


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


Re: PGADMIN3 request for preferences-related behavior change

От
Guillaume Lelarge
Дата:
On Sat, 2012-03-24 at 10:57 -0400, John Genoese wrote:
> It was actually 1.14 and 1.10. I got two machines confused.
>
>
> I use a Mac for development purposes. On it, I have a client that's on
> 8.4 and a client that's on 9.1. I cannot use the same PGADMIN3 tool
> for both precisely because of what you stated -- I need the different
> versions of pg_dump and pg_restore, but also because there's two
> completely discrete sets of database I must contend with.
>
>
> Hence, the idea of discrete configs for each. It's a significant pain
> to have to change the directories every time I switch clients.
>
>
> The simplest way I can think of to handle this is to make the config
> file path a startup parameter -- it could default to the normal one
> and let the user override it as necessary.
>

You can also create a script that will copy your 1.10 prefs file over
the regular pgAdmin prefs file, and then fire pgAdmin 1.10. And create
another script that will do the same thing with your 1.14 prefs file and
pgAdmin 1.14.

I know it's cumbersome, but we don't have another way of doing it right
now.

I agree that it would be nice to be able to change the config file. The
fact that we use the registry on Windows instead of a config file
doesn't make it easy to do.


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