Re: libpq API incompatibility between 7.4 and 8.0 - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: libpq API incompatibility between 7.4 and 8.0
Date
Msg-id 200502101715.j1AHFMZ06956@candle.pha.pa.us
Whole thread Raw
In response to libpq API incompatibility between 7.4 and 8.0  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Martin Pitt wrote:
-- Start of PGP signed section.
> Hi!
> 
> Bruce Momjian [2005-02-09 18:05 -0500]:
> > > However, I just stumbled across another problem: libpq3 and the new
> > > libpq4 use the same translation domain "libpq4", thus they cannot be
> > > installed in parallel. Can you please change the domain to "libpq4" as
> > > well? This should generally be done anyway, but at least we can live
> > > with one breakage of this rule (for libpq3), so that we don't need to
> > > mess with the old libpq3 package.
> > 
> > Uh, what is the translation domain?
> 
> In short, that is the unique name for a bunch of translations for a
> particular application or group of related applications. The key point
> is that the name of the file in
> /usr/share/locale/<LOCALE>/LC_MESSAGES/<DOMAIN>.mo and the call 
> 
>   bindtextdomain ("<DOMAIN>", NULL)

Well, that is certainly interesting.

> must use the same <DOMAIN> so that libintl can find the mo file.
> However, that means that all applications that are installed in
> parallel need a distinct domain. Since the whole point of SONAMes is
> to allow several different library API versions to be installed in
> parallel, every library API (i. e. SONAME) should have an unique
> domain, which can be achieved easiest by just appending the SONAME to
> the translation domain.

I see.  So we have to auto-populate the SONAME into all those places. 
Now that you mention it, it makes sense because the language strings are
fixed for every major release so I can see the need for this when using
two major versions of PostgreSQL.

---------------------------------------------------------------------------

> 
> In my test packages I used the following patch:
> 
> diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c postgresql-8.0.1/src/interfaces/libpq/fe-misc.c
> --- postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c 2004-12-31 23:03:50.000000000 +0100
> +++ postgresql-8.0.1/src/interfaces/libpq/fe-misc.c     2005-02-07 22:55:13.177419296 +0100
> @@ -1133,7 +1133,7 @@
>         {
>                 already_bound = 1;
>                 /* No relocatable lookup here because the binary could be anywhere */
> -               bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
> +               bindtextdomain("libpq4", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
>         }
> 
>         return dgettext("libpq", msgid);
> diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/nls.mk postgresql-8.0.1/src/interfaces/libpq/nls.mk
> --- postgresql-8.0.1-old/src/interfaces/libpq/nls.mk    2005-01-14 09:57:06.000000000 +0100
> +++ postgresql-8.0.1/src/interfaces/libpq/nls.mk        2005-02-07 22:54:54.770217616 +0100
> @@ -1,5 +1,5 @@
>  # $PostgreSQL: pgsql/src/interfaces/libpq/nls.mk,v 1.20 2005/01/14 08:57:06 petere Exp $
> -CATALOG_NAME   := libpq
> +CATALOG_NAME   := libpq4
>  AVAIL_LANGUAGES        := af cs de es fr hr it ko nb pl pt_BR ru sk sl sv tr zh_CN zh_TW
>  GETTEXT_FILES  := fe-auth.c fe-connect.c fe-exec.c fe-lobj.c fe-misc.c fe-protocol2.c fe-protocol3.c fe-secure.c
>  GETTEXT_TRIGGERS:= libpq_gettext pqInternalNotice:2
> 
> Compared to the SONAME, changing the translation domain is relatively
> uncritical, so if you don't want to change this upstream, I can
> maintain this patch for Debian/Ubuntu. However, I heard that some RPM
> guys plan a infrastructure similar to mine, and at that point they
> will have precisely the same problems :-)
> 
> Thanks for considering and have a nice day!
> 
> Martin
> -- 
> Martin Pitt                       http://www.piware.de
> Ubuntu Developer            http://www.ubuntulinux.org
> Debian GNU/Linux Developer       http://www.debian.org
-- End of PGP section, PGP failed!

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: slow SP with temporary tables, PLPGSQL problems
Next
From: "Bort, Paul"
Date:
Subject: Re: New form of index "persistent reference"