Bruce Momjian wrote:
With no one coming up with a better idea, this applied patch adds
PGETC (for pg_service.conf) and PGLOCALE (for locale dir) environment
variable processing to libpq.
Considering that in other places these locations are referred to as
sysconfdir and localdir, it would make
Peter Eisentraut wrote:
Bruce Momjian wrote:
With no one coming up with a better idea, this applied patch adds
PGETC (for pg_service.conf) and PGLOCALE (for locale dir) environment
variable processing to libpq.
Considering that in other places these locations are referred to as
With no one coming up with a better idea, this applied patch adds PGETC
(for pg_service.conf) and PGLOCALE (for locale dir) environment variable
processing to libpq.
The patch also adds code to our client apps so we set the environment
variable directly based on our binary location, unless it is
Am Donnerstag, 27. Mai 2004 13:05 schrieb Magnus Hagander:
I don't beleive this is a windows-specific issue. It's a general issue
for all relocateable installs.
Except that no one except Windows uses relocatable installs.
As for how to do it - on Windows you *can* get the path of the DLL that
Am Donnerstag, 27. Mai 2004 07:31 schrieb Bruce Momjian:
Sure, it is a hack, but what other option do we have? Do we somehow
move the locale files into the library?
On Windows we use the feature that DLLs can locate themselves (described by
Magnus Hagander), and on Unix we forget about
Am Donnerstag, 27. Mai 2004 14:41 schrieb Bruce Momjian:
As for how to do it - on Windows you *can* get the path of the DLL that
is executing your code, using GetModuleFileName(). Hardly
cross-platform, but can be done.
That sounds pretty reasonable to me.
True, and we already have
Peter Eisentraut wrote:
Am Donnerstag, 27. Mai 2004 14:41 schrieb Bruce Momjian:
As for how to do it - on Windows you *can* get the path of the DLL that
is executing your code, using GetModuleFileName(). Hardly
cross-platform, but can be done.
That sounds pretty reasonable to
Am Donnerstag, 27. Mai 2004 15:03 schrieb Bruce Momjian:
I will make a Win32-specific patch. Do we want an evironment variable
for Unix? Seems folks do. I will work on that too.
The gettext library already has an environment variable for that (NLSPATH I
think). I don't know if we need a
As for how to do it - on Windows you *can* get the
path of the
DLL that is executing your code, using GetModuleFileName().
Hardly cross-platform, but can be done.
That sounds pretty reasonable to me.
True, and we already have our own find_my_exec() which
works
Bruce Momjian [EMAIL PROTECTED] writes:
I will make a Win32-specific patch. Do we want an evironment variable
for Unix?
No, we do not. This entire thread has consisted of everyone but you
objecting loudly to that idea.
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I will make a Win32-specific patch. Do we want an evironment variable
for Unix?
No, we do not. This entire thread has consisted of everyone but you
objecting loudly to that idea.
They didn't sound very loud to me.
Why not have it
Peter Eisentraut wrote:
Bruce Momjian wrote:
I have two questions. First, setlocale() seemed to be inconsistently
set inside and outside of ENABLE_NLS. I assume the proper location
is inside.
No, in case of doubt it's outside.
OK, moved. New code is:
void
Andrew Dunstan wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Andrew Dunstan wrote:
I'm confused. Can you explain the problem more clearly, please? Do we
need to distinguish known apps with a known (relative) message
location, from unknown libpq clients?
Bruce Momjian wrote:
I am wondering if we should use environment variables, and have our
apps use putenv() to set it to the proper relative path.
The problem isn't our applications, it's someone else's applications.
Are you saying that from now on, setting certain environment variables
is
Peter Eisentraut wrote:
Bruce Momjian wrote:
I am wondering if we should use environment variables, and have our
apps use putenv() to set it to the proper relative path.
The problem isn't our applications, it's someone else's applications.
Are you saying that from now on, setting
Magnus found out that LOCALEDIR wasn't being handled in a relocatable
manner.
This patch fixes that. It also adjusts the get_*_path functions to
limit values to MAXPGPATH.
I have two questions. First, setlocale() seemed to be inconsistently
set inside and outside of ENABLE_NLS. I assume the
Bruce Momjian [EMAIL PROTECTED] writes:
I have two questions. First, setlocale() seemed to be inconsistently
set inside and outside of ENABLE_NLS. I assume the proper location is
inside.
Please do *not* go adding setlocale calls that were not there before.
You *will* break things.
!
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have two questions. First, setlocale() seemed to be inconsistently
set inside and outside of ENABLE_NLS. I assume the proper location is
inside.
Please do *not* go adding setlocale calls that were not there before.
You *will*
Bruce Momjian [EMAIL PROTECTED] writes:
OK, patch applied. Turns out it was only added for the backend
(postgres).
Hm? Isn't that code going to be executed in postmaster, bootstrap,
checkpoint processes, etc etc?
I don't really believe that path.c has any business doing this at
all, in any
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, patch applied. Turns out it was only added for the backend
(postgres).
Hm? Isn't that code going to be executed in postmaster, bootstrap,
checkpoint processes, etc etc?
I don't really believe that path.c has any business
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't really believe that path.c has any business doing this at
all, in any program.
Well, all our client apps used to do it in their own code. Now they
call set_pglocale to do it centrally and relocabably.
I don't care if the
Bruce Momjian [EMAIL PROTECTED] writes:
Well, as coded now, it will behave the same.
No it won't: as you have it, the postmaster and everything else that
goes through main.c will execute a setlocale call, which was not there
before for very good reasons.
regards, tom
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, as coded now, it will behave the same.
No it won't: as you have it, the postmaster and everything else that
goes through main.c will execute a setlocale call, which was not there
before for very good reasons.
I don't
Bruce Momjian [EMAIL PROTECTED] writes:
But I added code to path.c to skip that if the app is postgres. Why
doesn't that work?
That will work fine ... for a standalone backend. Not so fine for
postmaster or bootstrap or other cases that go through main.c.
regards, tom
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
But I added code to path.c to skip that if the app is postgres. Why
doesn't that work?
That will work fine ... for a standalone backend. Not so fine for
postmaster or bootstrap or other cases that go through main.c.
But they all
Bruce Momjian [EMAIL PROTECTED] writes:
But they all use the app name of postgres. They always did.
Oh! Sorry, I'm barking up the wrong tree then. I was thinking you were
looking at the exec_path.
regards, tom lane
---(end of
26 matches
Mail list logo
