Re: [PATCHES] Relocatable locale
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 sense to name the variables PGSYSCONFDIR and PGLOCALEDIR, so we stick to one set of terms. ---(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] Relocatable locale
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 sysconfdir and localdir, it would make sense to name the variables PGSYSCONFDIR and PGLOCALEDIR, so we stick to one set of terms. OK, change made. -- 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] Relocatable locale
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 already
set. This will allow our applications to emit proper locale messages
that are generated in libpq.
---
Bruce Momjian wrote:
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?
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 been proposed.
I am wondering if we should use environment variables, and have our apps
use putenv() to set it to the proper relative path.
It seems a bit roundabout, but might make sense. Maybe they shouldn't
override any value already present in the environment, just set it if
there is nothing there? Then the library could use the environment if
set, or fall back on a hardcoded path.
Yes, that is what I was thinking. Call it PGLOCALEDIR.
--
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
--
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.155
diff -c -c -r1.155 libpq.sgml
*** doc/src/sgml/libpq.sgml 14 May 2004 18:04:02 - 1.155
--- doc/src/sgml/libpq.sgml 2 Jun 2004 23:59:33 -
***
*** 3582,3587
--- 3582,3605
(Equivalent to literalSET geqo TO .../literal.)
/para
/listitem
+ listitem
+ para
+ indexterm
+ primaryenvarPGETC/envar/primary
+ /indexterm
+ envarPGETC/envar
+ sets the directory containing the filenamepg_service.conf/ file.
+ /para
+ /listitem
+ listitem
+ para
+ indexterm
+ primaryenvarPGLOCALE/envar/primary
+ /indexterm
+ envarPGLOCALE/envar
+ sets the directory containing the literallocale/ files.
+ /para
+ /listitem
/itemizedlist
Refer to the acronymSQL/acronym command commandSET/command
Index: src/backend/main/main.c
===
RCS file: /cvsroot/pgsql-server/src/backend/main/main.c,v
retrieving revision 1.85
diff -c -c -r1.85 main.c
*** src/backend/main/main.c 29 May 2004 22:48:19 - 1.85
--- src/backend/main/main.c 2 Jun 2004 23:59:41 -
***
*** 152,158
* allow startup error messages to be localized.
*/
! set_pglocale(argv[0], postgres);
#ifdef WIN32
--- 152,158
* allow startup error messages to be localized.
*/
! set_pglocale_pgservice(argv[0], postgres);
#ifdef WIN32
Index: src/bin/initdb/initdb.c
===
RCS file: /cvsroot/pgsql-server/src/bin/initdb/initdb.c,v
retrieving revision 1.34
diff -c -c -r1.34 initdb.c
*** src/bin/initdb/initdb.c 1 Jun 2004 02:53:59 - 1.34
--- src/bin/initdb/initdb.c 2 Jun 2004 23:59:53 -
***
*** 1788,1794
{global, pg_xlog, pg_clog, base, base/1};
progname = get_progname(argv[0]);
! set_pglocale(argv[0], initdb);
if (argc 1)
{
--- 1788,1794
{global, pg_xlog, pg_clog, base, base/1};
progname = get_progname(argv[0]);
! set_pglocale_pgservice(argv[0], initdb);
if (argc 1)
{
Index: src/bin/pg_controldata/pg_controldata.c
===
RCS file: /cvsroot/pgsql-server/src/bin/pg_controldata/pg_controldata.c,v
retrieving revision 1.16
diff -c -c -r1.16 pg_controldata.c
*** src/bin/pg_controldata/pg_controldata.c 25 May 2004 01:00:23 - 1.16
--- src/bin/pg_controldata/pg_controldata.c 2 Jun 2004 23:59:53 -
***
*** 77,83
char *strftime_fmt = %c;
const char *progname;
!
Re: [PATCHES] Relocatable locale
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 is executing your code, using GetModuleFileName(). Hardly cross-platform, but can be done. That sounds pretty reasonable to me. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Relocatable locale
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 pretending to offer relocatable installations. ---(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] Relocatable locale
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 our own find_my_exec() which works for Unix too. What does that have to do with this case? We're trying to find the library here. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Relocatable locale
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 me. True, and we already have our own find_my_exec() which works for Unix too. What does that have to do with this case? We're trying to find the library here. Oh, I see that GetModuleFileName() finds the location of your library, not of the binary. Nice. So, for Win32, we use that function call to find the locale directory? We do have a comment in port/exec.c: if (GetModuleFileName(NULL, retpath, MAXPGPATH) == 0) and I thought that did only binaries, not the library that uses them. I assume if the library is a DLL, it returns the DLL location, and if it is in the binary, it returns the binary location. I will make a Win32-specific patch. Do we want an evironment variable for Unix? Seems folks do. I will work on that too. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Relocatable locale
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 PostgreSQL-specific one. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Relocatable locale
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 for Unix too. What does that have to do with this case? We're trying to find the library here. Oh, I see that GetModuleFileName() finds the location of your library, not of the binary. Nice. So, for Win32, we use that function call to find the locale directory? We do have a comment in port/exec.c: if (GetModuleFileName(NULL, retpath, MAXPGPATH) == 0) and I thought that did only binaries, not the library that uses them. I assume if the library is a DLL, it returns the DLL location, and if it is in the binary, it returns the binary location. Nope, not quite. With the parameter NULL, it will return for the current *process*. You will need to use GetModuleHandle() (I think that should work) to get the handle of the DLL. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc /base/getmodulehandle.asp For static libaries, you need a different solution. Base that off the EXE? //Magnus ---(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] Relocatable locale
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 ---(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] Relocatable locale
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 so Unix folks can control it? Also, how do we get our native apps to know the location of the locale directory? The only other solution I can think of is a libpq function call to set it, but of course that can't be changed once the binary is created. Our apps could use the function call (based on the bin location), and other apps would have to decide how they would make this functionality visible, but it wouldn't be consistent. -- 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] Relocatable locale
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
set_pglocale(const char *argv0, const char *app)
{
#ifdef ENABLE_NLS
char path[MAXPGPATH];
char my_exec_path[MAXPGPATH];
#endif
/* don't set LC_ALL in the backend */
if (strcmp(app, postgres) != 0)
setlocale(LC_ALL, );
#ifdef ENABLE_NLS
if (find_my_exec(argv0, my_exec_path) 0)
return;
get_locale_path(my_exec_path, path);
bindtextdomain(app, path);
textdomain(app);
#endif
}
Second, libpq has a locale setting for error messages,
but a libpq program could be in any directory, so I see no way to
make that relocatable. Instead, I just use the hardcoded path. I
could make it relocatable, but that seems to error-prone, plus I
would have to look up the exec path and stuff, and it seemed too
complicated.
Hmm, so this says that a relocatable install isn't in fact possible?
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?
--
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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Relocatable locale
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? 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 been proposed. I am wondering if we should use environment variables, and have our apps use putenv() to set it to the proper relative path. It seems a bit roundabout, but might make sense. Maybe they shouldn't override any value already present in the environment, just set it if there is nothing there? Then the library could use the environment if set, or fall back on a hardcoded path. Yes, that is what I was thinking. Call it PGLOCALEDIR. -- 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] Relocatable locale
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 part of the required startup for libpq programs? Remember that on Windows in generall all installations are relocated away from the default location. ---(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] Relocatable locale
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 certain environment variables is part of the required startup for libpq programs? Remember that on Windows in generall all installations are relocated away from the default location. Well, if they want locale-specific error messages from libpq in their applications, the have to supply those locale files somehow. They could supply them in the same directory as their binaries and use putenv() and find_my_exec(). Sure, it is a hack, but what other option do we have? Do we somehow move the locale files into the library? -- 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
[PATCHES] Relocatable locale
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 proper location is
inside. Second, libpq has a locale setting for error messages, but a
libpq program could be in any directory, so I see no way to make that
relocatable. Instead, I just use the hardcoded path. I could make it
relocatable, but that seems to error-prone, plus I would have to look up
the exec path and stuff, and it seemed too complicated.
--
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: src/backend/main/main.c
===
RCS file: /cvsroot/pgsql-server/src/backend/main/main.c,v
retrieving revision 1.81
diff -c -c -r1.81 main.c
*** src/backend/main/main.c 24 May 2004 02:47:44 - 1.81
--- src/backend/main/main.c 25 May 2004 00:54:53 -
***
*** 150,155
--- 150,157
* startup error messages to be localized.
*/
+ set_pglocale(argv[0], postgres);
+
#ifdef WIN32
/*
* Windows uses codepages rather than the environment, so we work around
***
*** 184,194
setlocale(LC_MONETARY, C);
setlocale(LC_NUMERIC, C);
setlocale(LC_TIME, C);
-
- #ifdef ENABLE_NLS
- bindtextdomain(postgres, LOCALEDIR);
- textdomain(postgres);
- #endif
/*
* Skip permission checks if we're just trying to do --help or
--- 186,191
Index: src/bin/initdb/initdb.c
===
RCS file: /cvsroot/pgsql-server/src/bin/initdb/initdb.c,v
retrieving revision 1.32
diff -c -c -r1.32 initdb.c
*** src/bin/initdb/initdb.c 18 May 2004 03:36:36 - 1.32
--- src/bin/initdb/initdb.c 25 May 2004 00:54:56 -
***
*** 167,173
static bool chklocale(const char *locale);
static void setlocales(void);
static void usage(const char *progname);
! static void init_nls(void);
/*
--- 167,173
static bool chklocale(const char *locale);
static void setlocales(void);
static void usage(const char *progname);
! static void init_nls(const char *argv0);
/*
***
*** 1754,1766
* Initialized NLS if enabled.
*/
static void
! init_nls(void)
{
! #ifdef ENABLE_NLS
! setlocale(LC_ALL, );
! bindtextdomain(initdb, LOCALEDIR);
! textdomain(initdb);
! #endif
}
--- 1754,1762
* Initialized NLS if enabled.
*/
static void
! init_nls(const char *argv0)
{
! set_pglocale(argv0, initdb);
}
***
*** 1801,1807
* environment */
char *subdirs[] =
{global, pg_xlog, pg_clog, base, base/1};
! init_nls();
progname = get_progname(argv[0]);
--- 1797,1803
* environment */
char *subdirs[] =
{global, pg_xlog, pg_clog, base, base/1};
! init_nls(argv[0]);
progname = get_progname(argv[0]);
Index: src/bin/pg_controldata/Makefile
===
RCS file: /cvsroot/pgsql-server/src/bin/pg_controldata/Makefile,v
retrieving revision 1.7
diff -c -c -r1.7 Makefile
*** src/bin/pg_controldata/Makefile 30 Apr 2004 20:01:39 - 1.7
--- src/bin/pg_controldata/Makefile 25 May 2004 00:54:56 -
***
*** 14,20
override CPPFLAGS += -DFRONTEND
! OBJS= pg_controldata.o pg_crc.o
all: submake-libpgport pg_controldata
--- 14,20
override CPPFLAGS += -DFRONTEND
! OBJS= pg_controldata.o pg_crc.o exec.o
all: submake-libpgport pg_controldata
***
*** 24,29
--- 24,32
pg_crc.c: $(top_srcdir)/src/backend/utils/hash/pg_crc.c
rm -f $@ $(LN_S) $ .
+ exec.c: % : $(top_srcdir)/src/port/%
+ rm -f $@ $(LN_S) $ .
+
install: all installdirs
$(INSTALL_PROGRAM) pg_controldata$(X) $(DESTDIR)$(bindir)/pg_controldata$(X)
***
*** 34,37
rm -f $(DESTDIR)$(bindir)/pg_controldata$(X)
clean distclean maintainer-clean:
! rm -f pg_controldata$(X) pg_controldata.o pg_crc.o pg_crc.c
--- 37,40
rm -f $(DESTDIR)$(bindir)/pg_controldata$(X)
clean distclean maintainer-clean:
! rm -f pg_controldata$(X) pg_controldata.o pg_crc.o pg_crc.c exec.c
Index: src/bin/pg_controldata/pg_controldata.c
===
RCS file:
Re: [PATCHES] Relocatable locale
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. ! setlocale(LC_ALL, ); ^ Putting this call in the backend is a very serious mistake. It might be okay in clients, but not in the backend. regards, tom lane ---(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] Relocatable locale
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* break things. ! setlocale(LC_ALL, ); ^ Putting this call in the backend is a very serious mistake. It might be okay in clients, but not in the backend. OK, patch applied. Turns out it was only added for the backend (postgres). -- 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: src/port/path.c === RCS file: /cvsroot/pgsql-server/src/port/path.c,v retrieving revision 1.12 diff -c -c -r1.12 path.c *** src/port/path.c 25 May 2004 01:00:30 - 1.12 --- src/port/path.c 25 May 2004 01:40:36 - *** *** 251,257 char path[MAXPGPATH]; char my_exec_path[MAXPGPATH]; ! setlocale(LC_ALL, ); if (find_my_exec(argv0, my_exec_path) 0) return; --- 251,260 char path[MAXPGPATH]; char my_exec_path[MAXPGPATH]; ! /* don't set LC_ALL in the backend */ ! if (strcmp(app, postgres) != 0) ! setlocale(LC_ALL, ); ! if (find_my_exec(argv0, my_exec_path) 0) return; ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Relocatable locale
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 program. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Relocatable locale
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 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. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Relocatable locale
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 clients do it. I don't want main.c doing it. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Relocatable locale
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 lane ---(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] Relocatable locale
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 understand. I moved it up little in the file, but those calls were happening in that file before, just a little lower. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Relocatable locale
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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Relocatable locale
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 use the app name of postgres. They always did. That is not 'progname' but a hardcoded appname that is used in the main.c call. -- 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] Relocatable locale
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)--- TIP 7: don't forget to increase your free space map settings
