Re: Making pgxs builds work with a relocated installation - Mailing list pgsql-hackers

From Dave Page
Subject Re: Making pgxs builds work with a relocated installation
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4CC2F76@ratbert.vale-housing.co.uk
Whole thread Raw
In response to Making pgxs builds work with a relocated installation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 27 September 2005 18:57
> To: Magnus Hagander
> Cc: Dave Page; Peter Eisentraut; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Making pgxs builds work with a
> relocated installation
>
> "Magnus Hagander" <mha@sollentuna.net> writes:
> > Using GetShortPathName() will break on any system that has disabled
> > short filename generatino, which IIRC is a recommended best practice
> > both for performance and for security in legacy apps. I
> don't know what
> > it does, but probably it will just return the same long path again.
>
> Yuck.  Anyone have another idea on coping with space-containing
> pathnames?  I suppose we could try to quote the path
> variables properly
> in all the makefiles, but that sure seems like a painful proposition.

Actually it seems to work quite nicely - on Windows 2000 with short
names disabled it generates paths like:

C:\PROGRA~1\PostgreSQL\8.1-beta2\bin

Ie, it still fixes the spaces, but leaves the long bits, umm, long. With
short names enabled (on XP), you get:

C:\PROGRA~1\POSTGR~1\827E4~1.1-B\bin

Which is truly hideous, but works as expected in cmd.exe and Msys.

Patch attached that does this, and doubles up on the backslashes to keep
msys/make happy. Cmd.exe doesn't seem to care about the double
backslashes.

Regards, Dave

pgsql-hackers by date:

Previous
From: Dmitry Karasik
Date:
Subject: execution of prepared statements leaks memory
Next
From: "Kevin Grittner"
Date:
Subject: Re: [PERFORM] A Better External Sort?