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
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 woul
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
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 no
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
---
Magnus Hagander wrote:
> > > > > > 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.
> > > >
> > >
Peter Eisentraut wrote:
> 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
>
> > > > > 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 fi
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 P
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 prett
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
Peter Eisentraut wrote:
> 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.
I don't think that is completely true
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 prete
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 th
> > You wouldn't expect the environment var to be set by an app
> in those
> > cases - it would be set by a sysadmin or an installer on a
> system-wide
> > basis when pg is installed in other than the hardcoded location. At
> > least, that's the way I understood Bruce's suggestion.
>
> Strang
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
Andrew Dunstan wrote:
> You wouldn't expect the environment var to be set by an app in those
> cases - it would be set by a sysadmin or an installer on a
> system-wide basis when pg is installed in other than the hardcoded
> location. At least, that's the way I understood Bruce's suggestion.
Stran
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 p
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think the best we can do is putenv() for our apps, and document the
> > variable for other apps.
>
> Document what? How will another app find libpq's locale file?
> AFAICS *it can't*. Documenting a useless variable is not a soluti
Andrew Dunstan wrote:
> Tom Lane said:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I think the best we can do is putenv() for our apps, and document the
> >> variable for other apps.
> >
> > Document what? How will another app find libpq's locale file?
> > AFAICS *it can't*. Documenting a
Tom Lane said:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I think the best we can do is putenv() for our apps, and document the
>> variable for other apps.
>
> Document what? How will another app find libpq's locale file?
> AFAICS *it can't*. Documenting a useless variable is not a solution.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think the best we can do is putenv() for our apps, and document the
> variable for other apps.
Document what? How will another app find libpq's locale file?
AFAICS *it can't*. Documenting a useless variable is not a solution.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> The problem boils down to the fact that libpq needs to find its data
> >> files (in this case locale data, but it could be anything), but it
> >> doesn't know its own location, so it can't use a relative
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> The problem boils down to the fact that libpq needs to find its data
>> files (in this case locale data, but it could be anything), but it
>> doesn't know its own location, so it can't use a relative path
>> reference as has
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 unkno
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?
The problem boils down to the fact that libpq
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?
>
> The problem boils down to the fact that libpq needs to find its
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?
The problem boils down to the fact that libpq needs to find its data
files (in this case locale da
Bruce Momjian wrote:
Yep. I don't see how you can have a library know where to look for its
localized messages. The only thing I can think of is an environment
variable to override the hard-coded default. How is that?
I'm confused. Can you explain the problem more clearly, please? Do we
need
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
se
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.
> Second, libpq has a locale setting for error messages,
> but a libpq program could
Tom Lane wrote:
> 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.
Nope, hard-coded, as they all are. I could pull from argv[0], bu
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 broadcast)---
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
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 Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't understand. I moved it up little in the file, but those calls
> > were happening in that file before, just a little lower.
>
> No, *that* call wasn't happening at all. The calls that were there
> were setting certain limited,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't understand. I moved it up little in the file, but those calls
> were happening in that file before, just a little lower.
No, *that* call wasn't happening at all. The calls that were there
were setting certain limited, safe LC categories. You ad
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 un
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 l
Tom Lane wrote:
> 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 r
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 t
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
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
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.
> Y
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.
> !
45 matches
Mail list logo
