Peter Eisentraut wrote:
> Tom Lane wrote:
> > > What use could printing the relative path possibly have?
> >
> > Debugging. If I can't see it, I *know* I'm going to wish I could.
>
> Well, you can just look inside, it's not that big. Supporting extra
> options might make the script twice as big
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I guess what you are saying is we should have a configure-time option to
> >> address configured directories via relative paths from the executable's
> >> directory, rather than absolute paths? Seems reasonable ..
Tom Lane wrote:
> > What use could printing the relative path possibly have?
>
> Debugging. If I can't see it, I *know* I'm going to wish I could.
Well, you can just look inside, it's not that big. Supporting extra
options might make the script twice as big and thus make it harder to
just look
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We'd also need to give some thought to pg_config output. I think I
>> would like to be able to see the relative path computed by configure
>> as well as the effective actual path ... maybe a switch to specify
>> which way to print i
Tom Lane wrote:
> We'd also need to give some thought to pg_config output. I think I
> would like to be able to see the relative path computed by configure
> as well as the effective actual path ... maybe a switch to specify
> which way to print it?
What use could printing the relative path possi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I guess what you are saying is we should have a configure-time option to
>> address configured directories via relative paths from the executable's
>> directory, rather than absolute paths? Seems reasonable ...
> Yep. In fact, why wo
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Not sure how we can do this for Unix except perhaps probe PATH.
>
> Huh? We have always determined the full path of the executable ---
> see FindExec().
Oh, OK. I forgot that.
> I guess what you are saying is we should have a con
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Not sure how we can do this for Unix except perhaps probe PATH.
Huh? We have always determined the full path of the executable ---
see FindExec().
I guess what you are saying is we should have a configure-time option to
address configured directories v
Andrew Dunstan wrote:
> Claudio Natoli said:
> >
> >
> > Peter Eisentraut wrote:
> >> Claudio Natoli wrote:
> >> > I'm yet to see a convincing argument for why we can't adopt the
> >> > "binary-location/../share" approach as submitted late March. AFAICS,
> >> > it was rejected on the basis that it
Andrew Dunstan writes:
> How about if we have a configuration flag --enable-relocation which would
> require a fixed layout based on an indeterminate root. This would have the
> following effects:
>
> . if prefix did not contain 'postgres' or 'pgsql' then
> 'postgresql' would be appended.
> . al
Claudio Natoli said:
>
>
> Peter Eisentraut wrote:
>> Claudio Natoli wrote:
>> > I'm yet to see a convincing argument for why we can't adopt the
>> > "binary-location/../share" approach as submitted late March. AFAICS,
>> > it was rejected on the basis that it was not platform independent
>> > (no
Peter Eisentraut wrote:
> Claudio Natoli wrote:
> > Peter Eisentraut wrote:
> > > Claudio Natoli wrote:
> > > > I'm yet to see a convincing argument for why we can't adopt the
> > > > "binary-location/../share" approach as submitted late March.
> > > > AFAICS, it was rejected on the basis that it
> The only hard facts that we can use are hardcoded/compiled-in
> locations and explicit information passed via command-line
> arguments or environment variables. None of this seems to be
> useful for Windows installations. As far as I recall, the
> Windows installation routines only ask you
Peter Eisentraut wrote:
> Claudio Natoli wrote:
> > I'm yet to see a convincing argument for why we can't adopt the
> > "binary-location/../share" approach as submitted late March. AFAICS,
> > it was rejected on the basis that it was not platform independent (no
> > arguments there) and that we c
Claudio Natoli wrote:
> Peter Eisentraut wrote:
> > Claudio Natoli wrote:
> > > I'm yet to see a convincing argument for why we can't adopt the
> > > "binary-location/../share" approach as submitted late March.
> > > AFAICS, it was rejected on the basis that it was not platform
> > > independent (n
Claudio Natoli wrote:
> I'm yet to see a convincing argument for why we can't adopt the
> "binary-location/../share" approach as submitted late March. AFAICS,
> it was rejected on the basis that it was not platform independent (no
> arguments there) and that we could not rely on the ".." approach.
Andrew Dunstan wrote:
> >For Win32, we could use the registry. For Unix, we can't use /etc
> >because we can't be sure we are root. Can we create a dot-file in the
> >user's home directory during install?
> >
>
> We can't be sure we are Administrator either.
Exactly. IMHO, using the registr
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Binaries can find other binaries the way they do now: look in our own
location, then in the path.
No, we can't look into the path. We have no information that says that
anything useful pertaining to our installation is in the path.
Well, ass
Andrew Dunstan wrote:
> Binaries can find other binaries the way they do now: look in our own
> location, then in the path.
No, we can't look into the path. We have no information that says that
anything useful pertaining to our installation is in the path.
> Other files could be found by looki
Bruce Momjian wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
To make it work more cross-platform, replace "that registry thing"
with "postgresql.conf". It's basically the same thing, except the
registry has a hierarchy model.
That only works as long as all the files we want t
Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > To make it work more cross-platform, replace "that registry thing"
> > with "postgresql.conf". It's basically the same thing, except the
> > registry has a hierarchy model.
>
> That only works as long as all the files we want to refer to are use
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Common practice, for one thing. Windows programs are typically
relocatable, and Windows admins regard programs that rely on
hardcoded paths very poorly indeed.
OK, but how can that work in general? How do other programs handle
this? I don't
Magnus Hagander wrote:
> To make it work more cross-platform, replace "that registry thing"
> with "postgresql.conf". It's basically the same thing, except the
> registry has a hierarchy model.
That only works as long as all the files we want to refer to are used by
the server. But how will psql
>> Common practice, for one thing. Windows programs are typically
>> relocatable, and Windows admins regard programs that rely on
>> hardcoded paths very poorly indeed.
>
>OK, but how can that work in general? How do other programs handle
>this? I don't think we should design a solution that goe
Andrew Dunstan wrote:
> Common practice, for one thing. Windows programs are typically
> relocatable, and Windows admins regard programs that rely on
> hardcoded paths very poorly indeed.
OK, but how can that work in general? How do other programs handle
this? I don't think we should design a s
Bruce Momjian wrote:
> Tom Lane wrote:
> > I wrote:
> > > AFAICS the sharedir will already be sufficiently checked by means of
> > > initdb's check on the postgres.bki version marker. In some sense, the
> > > sharedir used by initdb is the *right* one for an installation by
> > > definition --- I'
Tom Lane wrote:
> I wrote:
> > AFAICS the sharedir will already be sufficiently checked by means of
> > initdb's check on the postgres.bki version marker. In some sense, the
> > sharedir used by initdb is the *right* one for an installation by
> > definition --- I'm not even convinced that we shou
I wrote:
> AFAICS the sharedir will already be sufficiently checked by means of
> initdb's check on the postgres.bki version marker. In some sense, the
> sharedir used by initdb is the *right* one for an installation by
> definition --- I'm not even convinced that we should allow people to
> fool
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> This is just going to open up the possibility of silently finding the
>> wrong files.
> Maybe it could be improved by using more version markers?
AFAICS the sharedir will already be sufficiently checked by means of
initdb's
Bruce Momjian wrote:
In other words:
#dynamic_library_path = '$libdir'
could maybe become:
#dynamic_library_path = '/usr/local/pgsql/lib'
Not sure I follow - dynamic_library_path is a colon-separated set of
paths. How will somone using $libdir have that resolved? ISTM we need to
Peter Eisentraut wrote:
Bruce Momjian wrote:
Also, Win32 installs are going to want to be more directory
independent than Unix.
Why?
Common practice, for one thing. Windows programs are typically
relocatable, and Windows admins regard programs that rely on hardcoded
paths very poorly ind
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Also, Win32 installs are going to want to be more directory
> > independent than Unix.
>
> Why?
Because when I install Win32 stuff on my machine via an installer, it
says "Where do you want the files" and puts it in C:\ or C:\Program
Files or wha
Bruce Momjian wrote:
> Also, Win32 installs are going to want to be more directory
> independent than Unix.
Why?
> Because Win32 can probe for the location of the binary, it seems it
> should check to see if it can find libdir and sharedir own its own
> and set those GUC values accordingly as par
I have been looking at our use of fixed directory specifications in
binaries.
Right now we have libdir (dynamic_library_path) predefined in the
compile, with a GUC to override it. initdb also needs to be able to
find its input files, and that can be overridden by an initdb flag.
Adding the timez
34 matches
Mail list logo
