Обсуждение: backup/restore buttons deactivated
Hi, i have a problem with pgadminIII 1.2.2 (deb build) on debian. I access a remote postgres database (8.0.3) on linux. the "Tools->Backup" and "Tools->Restore" functionality is always deactivated! Doesn't matter where i am in the database tree. About my system: * I don't have a local postgres database installed on my machine where the pgadminIII client is running. * The "/usr/pgsql/bin" directory on the remote linux machine is not in the path. could one of these be the reason for my problem? i can't install a local postgres db on my machine where pgadmin is running, nor can i change the path on the remote linux machine. or am i just missing a silly thing!? thanks, chris
Christian Sengstock wrote: > Hi, > i have a problem with pgadminIII 1.2.2 (deb build) on debian. I access > a remote postgres database (8.0.3) on linux. > > the "Tools->Backup" and "Tools->Restore" functionality is always > deactivated! Doesn't matter where i am in the database tree. > > About my system: > * I don't have a local postgres database installed on my machine where > the pgadminIII client is running. > * The "/usr/pgsql/bin" directory on the remote linux machine is not in the path. > > could one of these be the reason for my problem? You need the executables in the path for pgAdmin. Regards, Andreas
On Nov 18, 2005, at 5:45 AM, Andreas Pflug wrote: > You need the executables in the path for pgAdmin. I was wondering about this also for OS X. I got it to work by putting pg_dump and pg_restore inside pgAdmin OS X package (MacOS folder). Is this what you mean by "in the path" -- same directory as the executable? I could not find any information about setting this up in the documentation. BTW, the option to set the file location in OS X using the standard file dialog is broken (button with 3 dots next to the path). You can't specify a path unless you choose an existing file. Basically, an "open" file dialog is used rather than one that allows you to specify the path. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL
> -----Original Message----- > From: pgadmin-support-owner@postgresql.org > [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of John DeSoi > Sent: 18 November 2005 18:44 > To: Andreas Pflug > Cc: Christian Sengstock; pgadmin-support@postgresql.org > Subject: Re: [pgadmin-support] backup/restore buttons deactivated > > > On Nov 18, 2005, at 5:45 AM, Andreas Pflug wrote: > > > You need the executables in the path for pgAdmin. > > > I was wondering about this also for OS X. I got it to work by > putting > pg_dump and pg_restore inside pgAdmin OS X package (MacOS > folder). Is > this what you mean by "in the path" -- same directory as the > executable? No, though pgAdmin will look in it's own directory as well. Under the hood of OSX, in it's BSD roots you'll find it has an executable search path like DOS/Windows/Unix. You can check the path with something like "echo $PATH" from a command prompt. What I don't know offhand, is whether the path has any effect on things started from the Finder, or if it does, what shell is everything running under (and therefore, what script should be modified)? I will check this out when I'm next on my Mac. > I could not find any information about setting this up in the > documentation. > > BTW, the option to set the file location in OS X using the standard > file dialog is broken (button with 3 dots next to the path). You > can't specify a path unless you choose an existing file. Basically, > an "open" file dialog is used rather than one that allows you to > specify the path. And that. Regards, Dave.
On 19/11/05 9:46 pm, "Dave Page" <dpage@vale-housing.co.uk> wrote: > > >> -----Original Message----- >> From: pgadmin-support-owner@postgresql.org >> [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of John DeSoi >> Sent: 18 November 2005 18:44 >> To: Andreas Pflug >> Cc: Christian Sengstock; pgadmin-support@postgresql.org >> Subject: Re: [pgadmin-support] backup/restore buttons deactivated >> >> BTW, the option to set the file location in OS X using the standard >> file dialog is broken (button with 3 dots next to the path). You >> can't specify a path unless you choose an existing file. Basically, >> an "open" file dialog is used rather than one that allows you to >> specify the path. > > And that. Fixed in SVN. Regards, Dave
On Nov 19, 2005, at 4:46 PM, Dave Page wrote: > What I don't know offhand, is > whether the path has any effect on things started from the Finder, > or if > it does, what shell is everything running under (and therefore, what > script should be modified)? > > I will check this out when I'm next on my Mac. No, an application launched from the Dock or Finder won't have the user's search path. Here is link which explains it and one possible solution. But hopefully there is a better solution than creating a plist file. http://www.misplaced.net/fom/X11/36.html John John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL
> -----Original Message----- > From: John DeSoi [mailto:desoi@pgedit.com] > Sent: 21 November 2005 06:32 > To: Dave Page > Cc: Andreas Pflug; Christian Sengstock; pgadmin-support@postgresql.org > Subject: Re: [pgadmin-support] backup/restore buttons deactivated [re: pgadmin3.app not being able to find pg_dump/pg_restore] > On Nov 19, 2005, at 4:46 PM, Dave Page wrote: > > > What I don't know offhand, is > > whether the path has any effect on things started from the Finder, > > or if > > it does, what shell is everything running under (and therefore, what > > script should be modified)? > > > > I will check this out when I'm next on my Mac. > > > No, an application launched from the Dock or Finder won't have the > user's search path. Here is link which explains it and one possible > solution. > > But hopefully there is a better solution than creating a plist file. > > http://www.misplaced.net/fom/X11/36.html Thanks for the link. We do already have a plist file - the only sensible option I can think of is to add /usr/local/pgsql/bin (and whereever the dports version installs if it's different) to the path in it and hope the user installs PostgreSQL there. We can always include a note in the docs explaining how to adjust it if required. Unless anyone has a better idea? Florian or Richard perhaps? Regards, Dave.
> -----Original Message----- > From: Florian G. Pflug [mailto:fgp@phlo.org] > Sent: 21 November 2005 19:25 > To: Dave Page > Cc: John DeSoi; Andreas Pflug; Christian Sengstock; > pgadmin-support@postgresql.org; openmacnews@gmail.com > Subject: Re: [pgadmin-support] backup/restore buttons deactivated > > Dave Page wrote: > > Thanks for the link. We do already have a plist file - the > only sensible > > option I can think of is to add /usr/local/pgsql/bin (and > whereever the > > dports version installs if it's different) to the path in > it and hope > > the user installs PostgreSQL there. We can always include a > note in the > > docs explaining how to adjust it if required. > > > > Unless anyone has a better idea? Florian or Richard perhaps? > This code in appbase.cpp > ------------------------- > #if defined(__WXMAC__) > > //When using wxStandardPaths on OSX, wx defaults to the unix, > //not to the mac variants. Therefor, we request wxStandardPathsCF > //directly. > wxStandardPathsCF stdPaths ; > dataDir = stdPaths.GetDataDir() ; > > if (wxDir::Exists(dataDir + HELPER_DIR)) > path.Add(dataDir + HELPER_DIR) ; > if (wxDir::Exists(dataDir + SCRIPT_DIR)) > path.Add(dataDir + SCRIPT_DIR) ; > > #else // other *ixes > -------------------------- > > adds $bundledir/Contents/SharedSupport/helper to the path used by > pgadmin3. I think pgadmin3 should copy pg_dump and pg_restore into > that dir during "make install" - I remember trying to do that a while > ago, but couldn't find a reliable way to find the pg_dump and > pg_restore > while doing "make install". But since pgadmin3 now uses pg_config, I > guess the path to pg_dump and pg_restore could be queried > from pg_config. > > Another problem is that this won't guarantee that the version > of pg_dump > and pg_restore matches the version of the database which pg_dump and > pg_restore are trying to backup/restore - but that's a more general > problem - how does it work on windows, btw? We always build against the absolute latest version of PostgreSQL - pg_dump is backwards compatible so it should always work. Of course, it's not beyond he realms of possibility that it might produce a dump that cannot be re-imported into an old version of PostgreSQL, but if you run into that situation, about all you can do is either upgrade, or replace pg_dump with an older version. > I think that I can find a way to copy pg_dump and pg_restore into the > bundle (during "make install"), but I'll be very busy the > next few days, > so it'll have to wait until the weekend. OK, great - thanks. Regards, Dave.
Dave Page wrote:
> Thanks for the link. We do already have a plist file - the only sensible
> option I can think of is to add /usr/local/pgsql/bin (and whereever the
> dports version installs if it's different) to the path in it and hope
> the user installs PostgreSQL there. We can always include a note in the
> docs explaining how to adjust it if required.
>
> Unless anyone has a better idea? Florian or Richard perhaps?
This code in appbase.cpp
-------------------------
#if defined(__WXMAC__)
//When using wxStandardPaths on OSX, wx defaults to the unix, //not to the mac variants. Therefor, we request
wxStandardPathsCF //directly. wxStandardPathsCF stdPaths ; dataDir = stdPaths.GetDataDir() ;
if (wxDir::Exists(dataDir + HELPER_DIR)) path.Add(dataDir + HELPER_DIR) ; if (wxDir::Exists(dataDir +
SCRIPT_DIR)) path.Add(dataDir + SCRIPT_DIR) ;
#else // other *ixes
--------------------------
adds $bundledir/Contents/SharedSupport/helper to the path used by
pgadmin3. I think pgadmin3 should copy pg_dump and pg_restore into
that dir during "make install" - I remember trying to do that a while
ago, but couldn't find a reliable way to find the pg_dump and pg_restore
while doing "make install". But since pgadmin3 now uses pg_config, I
guess the path to pg_dump and pg_restore could be queried from pg_config.
Another problem is that this won't guarantee that the version of pg_dump
and pg_restore matches the version of the database which pg_dump and
pg_restore are trying to backup/restore - but that's a more general
problem - how does it work on windows, btw?
I think that I can find a way to copy pg_dump and pg_restore into the
bundle (during "make install"), but I'll be very busy the next few days,
so it'll have to wait until the weekend.
greetings, Florian Pflug
On Nov 21, 2005, at 4:49 PM, Dave Page wrote: > We always build against the absolute latest version of PostgreSQL - > pg_dump is backwards compatible so it should always work. Of course, > it's not beyond he realms of possibility that it might produce a dump > that cannot be re-imported into an old version of PostgreSQL, but > if you > run into that situation, about all you can do is either upgrade, or > replace pg_dump with an older version. The effort may not be warranted here, but for my applications which need PostgreSQL utilities I have 3 options: 1. built-in version included with the distribution (default) 2. whatever is found on the program path 3. the user can specify the PostgreSQL bin path to use > > >> I think that I can find a way to copy pg_dump and pg_restore into the >> bundle (during "make install"), but I'll be very busy the >> next few days, >> so it'll have to wait until the weekend. >> > > OK, great - thanks. Excellent, I think this is the best option. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL
John DeSoi wrote: >>> I think that I can find a way to copy pg_dump and pg_restore into the >>> bundle (during "make install"), but I'll be very busy the >>> next few days, >>> so it'll have to wait until the weekend. >>> >> >> OK, great - thanks. > > Excellent, I think this is the best option. The latest nighty build, available at http://developer.pgadmin.org/snapshots/osx/pgadmin3-trunk-20051125.tar.bz2 should have pg_dump and pg_restore included. Please test if it works for you - I tried dumping a small db, and it worked - didn't test restore though. greetings, Florian Pflug
On Nov 24, 2005, at 6:14 PM, Florian G. Pflug wrote: > The latest nighty build, available at > http://developer.pgadmin.org/snapshots/osx/pgadmin3- > trunk-20051125.tar.bz2 > should have pg_dump and pg_restore included. Please test if it > works for you - I tried dumping a small db, and it worked - didn't > test restore though. Both backup and restore seem to be working. And thanks for fixing the file dialog on the backup interface. John John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL