Martin Pitt wrote:
> Hi!
> Peter Eisentraut [2005-06-25 11:29 +0200]:
> > Am Samstag, 25. Juni 2005 04:24 schrieb Bruce Momjian:
> > > We absolutely want to support multiple installed versions of PostgreSQL.
> > 
> > But we don't support installing multiple versions on top of each other, 
> > which 
> > is the only scenario where this patch would be useful.
> It's not "on top of each other", but side-by-side as Bruce says. The
> single clusters and their postmaster do not influence each other in
> Debian.

I have looked now at the bindtextdomain() code in current CVS and 8.0.X.

We basically have only two bindtextdomain() calls.  libpq has this code:

        bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : 

It basically uses either the environment variable PGLOCALEDIR, or the
hard-coded compile-time LOCALEDIR value.  I don't see how adding a
version number to the "libpq" string would help unles PGLOCALEDIR points
to a directory that has both libpq-7.4 and libpq-8.0 directories with
translations, and I didn't see your setup using that.

Our applications call set_pglocale_pgservice(), which makes two
bindtextdomain() calls.  It calls set_pglocale_pgservice(), like this:

            set_pglocale_pgservice(argv[0], "psql");

The locale files for the application are found relative to the directory
containing the binary.  It also sets the environment variable
PGLOCALEDIR so libpq can find its local files.

Based on this analsys, I don't understand what adding the PostgreSQL
version number does for us.

  Bruce Momjian                        |               |  (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 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to