[pgadmin-support] installation problem
when i install postgresql it shows error of openssl.after installation it cannot connect to database.
Re: [pgadmin-support] weird problem with pgadmin & postgres on debian
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alessandro @ GMailSent: 18 March 2006 17:26To: pgadmin-support@postgresql.orgSubject: Re: [pgadmin-support] weird problem with pgadmin & postgres on debian mmm i think you're right and it's not the same installation as i have not defined the PGDATA environment variable yet, so i don't know what he started at boot time...(i run the db with the -D option right now)another thing i forgot to say is that the first time i put the data folder in my user home(/home/alex/.postgres/data) instead of /usr/local/pgsql/data/ ...but user postgres should be a SU so it shouldn't make any difference, or am i wrong? then i changed the folder to /usr/local/pgsql/data/ but pgadmin refused still to connect. Only after i slaughtered /etc/init.d/postgresql-8.1 i was able to connect with pgadmin... Sounds like you are in a proper mess of defaults, command line options and envvars!! I'd hunt down all clusters (maybe, find / -name postgresql.conf), figure out which one you want to start, and then make sure that you either start it with the -D option, or by explicitly setting $PGDATA first. Don't rely on su to preserve the environment or anything like that as you're bound to run into trouble as soon as you type 'su - postgres' instead of 'su postgres' without thinking. Regards, Dave
Re: [pgadmin-support] Help
Hi. From: "Henry Andres Sanabria Fuentes" > I dont' speak english good. > > How setting Slony I on Win32. > I have pgadmin 1.4 You can know details below. http://pgfoundry.org/projects/slony1/ However, Slony-I Version 1.2 is needed as a version to which Windows operates. Then, It will be necessary to know that it is not supplied as a stable version. Furthermore, probably, many information is needed in order that you may compile it from a source code. However, We think that we need to prepare it on a document more intelligibly. I have the binary pack which can be examined here. http://developer.pgadmin.org/~hiroshi/ I think that we wants to carry out this update timely, if possible. However, That will be suitable if an Slony-I team accepts. Probably, discussion should be performed there Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-support] Invalid password for \ and ' characters
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Andreas Pflug > Sent: 19 March 2006 11:19 > To: Andrus Moor > Cc: pgadmin-support@postgresql.org > Subject: Re: [pgadmin-support] Invalid password for \ and ' characters > > Andrus Moor wrote: > > If password set by pgadmin contains \ or ' character, it is > not possible to > > login to pgAdmin > > > > PROBLEM WITH \ character is password > > > > To reproduce > > > > 1. Create new login role in pgadmin > > 2. Enter \ to password field. > > 3. Select SQL tab > > > > Observed: > > > > CREATE ROLE test LOGIN PASSWORD '\\' > > > > Expected > > > > CREATE ROLE test LOGIN PASSWORD '\' > > > > Postres does NOT require backslashes in password strings. > > PgAdmin probably uses its qtString for password strings. > > AFAIR Dave recently changed that. Please check the CHANGELOG > and try a > newer version. Yes, I did, but that was for the logon code where the rules of libpq are observed rather than SQL. As per the example given, Andrus has it backwards. The password string in PostgreSQL is just like any other string and will always require that quotes and backslashes are escaped. Note in psql, how the prompt shows the string is to be completed if a backslash is not quoted: postgres=> alter role dpage with password '\'; postgres'> Regards, Dave. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-support] Mac version can't dump/restore
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John DeSoi > Sent: 16 March 2006 14:29 > To: pgadmin-support@postgresql.org > Subject: [pgadmin-support] Mac version can't dump/restore > > The problem is the pg_dump utility hard codes the path of > libpq. This > is not very workable because not only can that be customized, some > one using pgAdmin might not have PostgreSQL installed at all on the > local machine. Hmm, yes - it seems the build script was assuming GNU xargs, whereas on the build machine I have the standard BSDish one. I've added some detection code to the script so it should work with either now. > Also, I noticed that the pgAdmin package has PkgInfo at the same > level as the Contents folder. I thought it should be in the Contents > folder. Yup, quite correct from what I can see in the Apple docs. Thanks for the reports - fixes will be committed shortly. Regards, Dave ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-support] Mac version can't dump/restore
Hi Dave, On Mar 20, 2006, at 6:30 AM, Dave Page wrote: Hmm, yes - it seems the build script was assuming GNU xargs, whereas on the build machine I have the standard BSDish one. I've added some detection code to the script so it should work with either now. So why do this rather than include libpq in the package so there is no path dependency at all? I thought this is what you are doing on Windows already. Just curious. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-support] Mac version can't dump/restore
> -Original Message- > From: John DeSoi [mailto:[EMAIL PROTECTED] > Sent: 20 March 2006 14:47 > To: Dave Page > Cc: pgadmin-support@postgresql.org > Subject: Re: [pgadmin-support] Mac version can't dump/restore > > Hi Dave, > > On Mar 20, 2006, at 6:30 AM, Dave Page wrote: > > > Hmm, yes - it seems the build script was assuming GNU xargs, > > whereas on > > the build machine I have the standard BSDish one. I've added some > > detection code to the script so it should work with either now. > > So why do this rather than include libpq in the package so there is > no path dependency at all? I thought this is what you are doing on > Windows already. > > Just curious. We already did basically what you suggested as part of the install process when building an appbundle - the problem was that the script that locates and copies in the libraries was failing due to the xargs bug. The error message simply went unnoticed in the other reams of output that make install spews out, and because I normally statically link wx, it only affected people who didn't have a local install of PostgreSQL which is presumably fairly rare. Of course, that begs the question, why isn't PostgreSQL being statically linked as well, but that's a whole other issue. The script is at http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/trunk/pgadmin3/pkg/mac/comple te-bundle.sh?rev=5055&view=markup if you want a peek. Regards, Dave. ---(end of broadcast)--- TIP 6: explain analyze is your friend
[pgadmin-support] Anyone got an Intel Mac yet?
Does anyone have an Intel Mac that they would be willing do try building pgAdmin on? There's certainly one script that will fail, but I'm kinda hoping that will be all :-). It would be good to know for sure, and be able to fix the script (lines 20/26 of http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/trunk/pgadmin3/pkg/mac/comple te-bundle.sh?rev=5055&view=markup presumably need 'ppc' changed to 'i386' or 'intel' or something). Cheers, Dave. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
