Re: [PATCHES] Compiling libpq with VC6
Bruce Momjian wrote: The problem with this approach is that it has us using the non-reliable libc rename/unlink rather than our own in libpq. Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [pgsql-hackers-win32] 8.0 Beta 1 // Environment Vars // .pgpass
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: 18 August 2004 03:59 To: Andrew Dunstan Cc: Joerg Hessdoerfer; [EMAIL PROTECTED]; PostgreSQL-patches Subject: Re: [pgsql-hackers-win32] 8.0 Beta 1 // Environment Vars // .pgpass I have applied the attached patch which adds get_home_path() which uses USERPROFILE on Win32 and HOME on Unix. This should fix the reported problem. I now get the following error on Win32 following a make distclean: fe-connect.o(.text+0x3428):fe-connect.c: undefined reference to `get_home_path' c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1 make[3]: *** [libpq.a] Error 1 make[3]: Leaving directory `/cvs/pgsql/src/interfaces/libpq' make[2]: *** [all] Error 2 make[2]: Leaving directory `/cvs/pgsql/src/interfaces' make[1]: *** [all] Error 2 make[1]: Leaving directory `/cvs/pgsql/src' make: *** [all] Error 2 :-( Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pg_restore recognizing $-quotes
At 01:44 PM 18/08/2004, Bruce Momjian wrote: This is quite a large patch, but we do need a solution to this problem. Should it be applied? It's not as large as you might think; I had to indent a large chunk of code, and that shows up in the diff. Try applying it, and looking at a 'diff -b'. There are two issues that I can see: - I think the logic used to check for $-quotes is valid, but someone else should look at it. - Adding a full parser would be too big a change for now; and should be avoided if possible. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp.mit.edu:11371 |/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pg_restore recognizing $-quotes
Andrew Dunstan [EMAIL PROTECTED] writes: ISTM that a very simple alternative would be to force pg_dump to inhibit dollar quoting for non-text dumps. I don't want to do that, but I did think that a simpler alternative would be to inhibit pg_restore from attempting to parse FUNCTION entries. I can't see any strong need for it to do so. (I haven't had time to review Philip's patch either... but I think Bruce was asking whether to put it on the awaiting review list... definitely yes.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] pg_restore recognizing $-quotes
At 12:47 AM 19/08/2004, Tom Lane wrote: I don't want to do that, but I did think that a simpler alternative would be to inhibit pg_restore from attempting to parse FUNCTION entries. I can't see any strong need for it to do so. I don't like hard-coding stuff based on the TOC tags; but we *might* be able to get away with a more general rule: do not parse if it's an object definition (as opposed to data). In the longer term I think we will need to continue to parse TOC entries. In playing around with pg_dump(all), I put user definitions in one TOC entry. For those, we will need to add as many users as possible and ignore individual failures (something we can't to if a single multi-statement string is sent to the backend). Other TOC entries may need to be atomic. Not sure. If the patch is not kosher, then I'd vote for adding a do not parse flag on the TOC entries when dumping them. Or a statement count. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp.mit.edu:11371 |/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pg_restore recognizing $-quotes
Philip Warner [EMAIL PROTECTED] writes: If the patch is not kosher, then I'd vote for adding a do not parse flag on the TOC entries when dumping them. Or a statement count. Unless you plan to abandon compatibility with existing dump files, this doesn't seem like much of a solution ... pg_restore will still have to include code to figure it out for itself ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pg_restore recognizing $-quotes
Tom Lane said: Andrew Dunstan [EMAIL PROTECTED] writes: ISTM that a very simple alternative would be to force pg_dump to inhibit dollar quoting for non-text dumps. I don't want to do that, but I did think that a simpler alternative would be to inhibit pg_restore from attempting to parse FUNCTION entries. I can't see any strong need for it to do so. (I haven't had time to review Philip's patch either... but I think Bruce was asking whether to put it on the awaiting review list... definitely yes.) OK. Not sure I understand why, though - the whole point of putting dollar quoting into pg_dump was to make text dumps nicer to read, I thought (and I outght to know ;-) ). Once the function is created you have no idea at all if the body was originally dollar quoted or not. cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] pg_restore recognizing $-quotes
Per Tom ... Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Philip Warner wrote: Not sure if this is the desired approach, but since it works, I thought I'd send it. This patch allows pg_restore to recognize $-quotes in SQL queries. It will treat any unquoted string that starts with a $ and has no preceding identifier chars as a potential $-quote tag, it then makes sure that the tag chars are valid. If so, it processes the $-quote. Tested against local DBs and regression DB. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp.mit.edu:11371 |/ [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pg_restore recognizing $-quotes
Andrew Dunstan [EMAIL PROTECTED] writes: ISTM that a very simple alternative would be to force pg_dump to inhibit dollar quoting for non-text dumps. ... OK. Not sure I understand why, though - the whole point of putting dollar quoting into pg_dump was to make text dumps nicer to read, I thought (and I outght to know ;-) ). But you can get a text dump out of pg_restore. Also, for testing purposes I think it's important that pg_dump -Fc | pg_restore generate exactly the same script as pg_dump. This is true currently (unless someone's broken it again recently) and I don't want to give up the property. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pg_restore recognizing $-quotes
Tom Lane wrote: Also, for testing purposes I think it's important that pg_dump -Fc | pg_restore generate exactly the same script as pg_dump. This is true currently (unless someone's broken it again recently) and I don't want to give up the property. Ok, that part I certainly buy. cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [BUGS] 8.0.0beta1: -lpthread missing
Bruce Momjian wrote: OK, I found the cause. I forgot to run autoconf after the config/acx_pthread.m4 updated. I just did so. Please retest. Thanks. Ok, I did an cvs update and rerun configure. Now it gives me an error: [...] checking whether pthreads work with -pthread... no checking whether pthreads work with -pthreads... yes checking for the pthreads library -lpthread... yes checking whether pthreads work with -mt... yes checking for the pthreads library -lpthreads... yes checking whether pthreads work without any flags... yes checking whether pthreads work with -Kthread... yes checking whether pthreads work with -kthread... yes checking for the pthreads library -llthread... yes checking whether pthreads work with -pthread... yes checking whether pthreads work with -pthreads... yes checking whether pthreads work with -mthreads... yes checking for the pthreads library -lpthread... yes checking whether pthreads work with --thread-safe... yes checking whether pthreads work with -mt... yes checking for joinable pthread attribute... unknown configure: WARNING: we do not know how to create joinable pthreads [Oooops.] checking if more special flags are required for pthreads... no checking for cc_r... gcc checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for strerror_r... no checking for getpwuid_r... no checking for gethostbyname_r... no checking whether getpwuid_r takes a fifth argument... no checking whether strerror_r returns int... no [...] checking thread safety of required library functions... no configure: error: *** Thread test program failed. Your platform is not thread-safe. *** Check the file 'config.log'for the exact reason. *** *** You can use the configure option --enable-thread-safety-force *** to force threads to be enabled. However, you must then run *** the program in src/tools/thread and add locking function calls *** to your applications to guarantee thread safety. Bruce, I will send you my config.log privately. Regards, Martin -= -- Martin M=FCnstermann wrote: Bruce Momjian wrote: -- We need -lpthread on solaris, too. =20 =20 So the current CVS code is good? =20 No. At least not for solaris8. =20 configure says: checking whether pthreads work with -pthread... no checking whether pthreads work with -pthreads... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking for cc_r... gcc checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes =20 =20 Makefile.global: PTHREAD_CFLAGS =3D -pthreads -D_REENTRANT -D_THREAD_SAFE=20 -D_POSIX_PTHREAD_SEMANTICS PTHREAD_LIBS=3D =20 No -lpthread and the resulting binaries have no dependancy on=20 libpthread.so, so at runtime only the stubs are being called. =20 Regards, Martin =20 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [BUGS] 8.0.0beta1: -lpthread missing
Bruce Momjian wrote: -- We need -lpthread on solaris, too. So the current CVS code is good? No. At least not for solaris8. configure says: checking whether pthreads work with -pthread... no checking whether pthreads work with -pthreads... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking for cc_r... gcc checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes Makefile.global: PTHREAD_CFLAGS = -pthreads -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS PTHREAD_LIBS= No -lpthread and the resulting binaries have no dependancy on libpthread.so, so at runtime only the stubs are being called. Regards, Martin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [pgsql-hackers-win32] 8.0 Beta 1 // Environment Vars // .pgpass
Wow, that is strange. Did you do a 'make clean' before this? I don't see why you would see the failure on Win32 and I don't see it on Unix. Hold, we might have problems later on this for linking client apps because as I remember win32 doesn't like the same symbol used in libpq and pgport, but you haven't even gotten to that stage yet in the compile. The workaround has been to make the function call a macro but let's get libpq compiled first and see how it goes after that. --- Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: 18 August 2004 03:59 To: Andrew Dunstan Cc: Joerg Hessdoerfer; [EMAIL PROTECTED]; PostgreSQL-patches Subject: Re: [pgsql-hackers-win32] 8.0 Beta 1 // Environment Vars // .pgpass I have applied the attached patch which adds get_home_path() which uses USERPROFILE on Win32 and HOME on Unix. This should fix the reported problem. I now get the following error on Win32 following a make distclean: fe-connect.o(.text+0x3428):fe-connect.c: undefined reference to `get_home_path' c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1 make[3]: *** [libpq.a] Error 1 make[3]: Leaving directory `/cvs/pgsql/src/interfaces/libpq' make[2]: *** [all] Error 2 make[2]: Leaving directory `/cvs/pgsql/src/interfaces' make[1]: *** [all] Error 2 make[1]: Leaving directory `/cvs/pgsql/src' make: *** [all] Error 2 :-( Regards, Dave. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Compiling libpq with VC6
Andreas Pflug wrote: Bruce Momjian wrote: The problem with this approach is that it has us using the non-reliable libc rename/unlink rather than our own in libpq. Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. I would like to keep full Unix semantics for these functions even in libpq, if possible. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Compiling libpq with VC6
Bruce Momjian [EMAIL PROTECTED] writes: Andreas Pflug wrote: Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. I would like to keep full Unix semantics for these functions even in libpq, if possible. libpq doesn't use either rename or unlink AFAIK. However, if we make the patch be something involving #ifdef FRONTEND, then it will affect other code that might want to use those. One thing that hasn't been real clear to me is why this only affects fe-lobj.c, when we have many other files that include io.h after including postgres.h. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Compiling libpq with VC6
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Andreas Pflug wrote: Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. I would like to keep full Unix semantics for these functions even in libpq, if possible. libpq doesn't use either rename or unlink AFAIK. However, if we make the patch be something involving #ifdef FRONTEND, then it will affect other code that might want to use those. One thing that hasn't been real clear to me is why this only affects fe-lobj.c, when we have many other files that include io.h after including postgres.h. Quite simple: mingw includes do *not* conflict. Only a minority of tools is object to VC6 compilation, ultimately only libpq is needed. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Compiling libpq with VC6
Andreas Pflug wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Andreas Pflug wrote: Not really. The backend will still use the reliable pg_ functions. Frontends continue to use the libc functions, which are totally sufficient in non-concurrent access situations. I would like to keep full Unix semantics for these functions even in libpq, if possible. libpq doesn't use either rename or unlink AFAIK. However, if we make the patch be something involving #ifdef FRONTEND, then it will affect other code that might want to use those. One thing that hasn't been real clear to me is why this only affects fe-lobj.c, when we have many other files that include io.h after including postgres.h. Quite simple: mingw includes do *not* conflict. Only a minority of tools is object to VC6 compilation, ultimately only libpq is needed. True, only MSVC conflicted. Maybe no one has compiled anything but libpq using MSVC, particularly psql. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Compiling libpq with VC6
Tom Lane wrote: Hm. Given that we now support a native Windows port, do we care about building libpq with VC6 anymore? Yes please! I just tried: I renamed libpq.a to libpq.lib. pgAdmin links with that, but will crash. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Compiling libpq with VC6
Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: One thing that hasn't been real clear to me is why this only affects fe-lobj.c, when we have many other files that include io.h after including postgres.h. Quite simple: mingw includes do *not* conflict. Only a minority of tools is object to VC6 compilation, ultimately only libpq is needed. Hm. Given that we now support a native Windows port, do we care about building libpq with VC6 anymore? Why wouldn't you just use the library as built with mingw? If we were moving in the direction of making the whole project buildable with VC6, that would be one thing; but as far as I know that is explicitly not part of the plan. So why should we continue to support a partially-baked port when we have a full port? VC seems broken only in the very minor way of io.h. I don't know of any other issues. Doesn't seem like enough of a reason to abandon the build environment. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] pg_restore recognizing $-quotes
At 01:33 AM 19/08/2004, Tom Lane wrote: pg_dump -Fc | pg_restore generate exactly the same script as pg_dump. Hard to believe this was not always true. Not sure I like the requirement that pg_restore to a database behave just like 'pg_restore | psql', though 8-}. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] pg_restore recognizing $-quotes
At 01:22 AM 19/08/2004, Tom Lane wrote: Philip Warner [EMAIL PROTECTED] writes: If the patch is not kosher, then I'd vote for adding a do not parse flag on the TOC entries when dumping them. Or a statement count. Unless you plan to abandon compatibility with existing dump files, this doesn't seem like much of a solution Not really; pg_restore is able to read all old formats; in the case of old dump files it would behave as though statement count 1. In the case of new dump files, it would use the statement count. It's only new dump files that exhibit the problem, so this will work. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp.mit.edu:11371 |/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] 8.0 libpq: missing get_home_path()
OK, patch attached and applied. I also updated the docs.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I need to call canonicalize_path() in the macro.
There is only one use of get_home_path in libpq. Lose it and do
a direct getenv(HOMEDIR). You do not really need to do a
canonicalize_path there; it'd be sufficient to insert the appropriate
directory separator ('/' or '\') when forming pgpassfile just below.
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/libpq.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v
retrieving revision 1.160
diff -c -c -r1.160 libpq.sgml
*** doc/src/sgml/libpq.sgml 17 Aug 2004 16:54:46 - 1.160
--- doc/src/sgml/libpq.sgml 18 Aug 2004 23:54:05 -
***
*** 136,142
likely to fail if applicationlibpq/application is passed a host name
that is not the name of the machine at literalhostaddr/.) Also,
literalhost/ rather than literalhostaddr/ is used to identify
! the connection in filename$HOME/.pgpass/.
/para
para
Without either a host name or host address,
--- 136,143
likely to fail if applicationlibpq/application is passed a host name
that is not the name of the machine at literalhostaddr/.) Also,
literalhost/ rather than literalhostaddr/ is used to identify
! the connection in filename$HOME/.pgpass/ (or
! filename%USERPROFILE%/.pgpass/ on Win32).
/para
para
Without either a host name or host address,
Index: src/interfaces/libpq/fe-connect.c
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.281
diff -c -c -r1.281 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 18 Aug 2004 02:59:11 - 1.281
--- src/interfaces/libpq/fe-connect.c 18 Aug 2004 23:54:19 -
***
*** 3093,3099
{
FILE *fp;
char *pgpassfile;
! char home[MAXPGPATH];
struct stat stat_buf;
#define LINELEN NAMEDATALEN*5
--- 3093,3099
{
FILE *fp;
char *pgpassfile;
! char *home;
struct stat stat_buf;
#define LINELEN NAMEDATALEN*5
***
*** 3111,3120
if (port == NULL)
port = DEF_PGPORT_STR;
! /* Look for it in the home dir */
! if (!get_home_path(home))
return NULL;
!
pgpassfile = malloc(strlen(home) + 1 + strlen(PGPASSFILE) + 1);
if (!pgpassfile)
{
--- 3111,3123
if (port == NULL)
port = DEF_PGPORT_STR;
! /*
!* Look for it in the home dir.
!* We don't use get_home_path() so we don't pull path.c into our library.
!*/
! if (!(home = getenv(HOMEDIR)))
return NULL;
!
pgpassfile = malloc(strlen(home) + 1 + strlen(PGPASSFILE) + 1);
if (!pgpassfile)
{
***
*** 3122,3128
--- 3125,3135
return NULL;
}
+ #ifndef WIN32
sprintf(pgpassfile, %s/%s, home, PGPASSFILE);
+ #else
+ sprintf(pgpassfile, %s\\%s, home, PGPASSFILE);
+ #endif
/* If password file cannot be opened, ignore it. */
if (stat(pgpassfile, stat_buf) == -1)
---(end of broadcast)---
TIP 3: 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: [PATCHES] [pgsql-hackers-win32] 8.0 Beta 1 // Environment Vars // .pgpass
I found the cause and just applied a fix. Thanks. --- Bruce Momjian wrote: Wow, that is strange. Did you do a 'make clean' before this? I don't see why you would see the failure on Win32 and I don't see it on Unix. Hold, we might have problems later on this for linking client apps because as I remember win32 doesn't like the same symbol used in libpq and pgport, but you haven't even gotten to that stage yet in the compile. The workaround has been to make the function call a macro but let's get libpq compiled first and see how it goes after that. --- Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: 18 August 2004 03:59 To: Andrew Dunstan Cc: Joerg Hessdoerfer; [EMAIL PROTECTED]; PostgreSQL-patches Subject: Re: [pgsql-hackers-win32] 8.0 Beta 1 // Environment Vars // .pgpass I have applied the attached patch which adds get_home_path() which uses USERPROFILE on Win32 and HOME on Unix. This should fix the reported problem. I now get the following error on Win32 following a make distclean: fe-connect.o(.text+0x3428):fe-connect.c: undefined reference to `get_home_path' c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1 make[3]: *** [libpq.a] Error 1 make[3]: Leaving directory `/cvs/pgsql/src/interfaces/libpq' make[2]: *** [all] Error 2 make[2]: Leaving directory `/cvs/pgsql/src/interfaces' make[1]: *** [all] Error 2 make[1]: Leaving directory `/cvs/pgsql/src' make: *** [all] Error 2 :-( Regards, Dave. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
