MIME-Version: 1.0
References: <CABvPt_xtYyvFfyupGn=TXNGnEAFd0m_ARPFpDUWBcn603aM84w@mail.gmail.com>
 <1554256.1729521467@sss.pgh.pa.us>
In-Reply-To: <1554256.1729521467@sss.pgh.pa.us>
Reply-To: zarkonesmall@gmail.com
From: Anatolii Smolianinov <zarkonesmall@gmail.com>
Date: Mon, 21 Oct 2024 17:03:14 +0200
Message-ID: <CABvPt_zjW7oVeYg9SMtYre0cG_Jm_mxPiErZMvf2Eco-hOcDxA@mail.gmail.com>
Subject: Re: Timezone: resolve $TZDIR in runtime
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000006350d80624fdf4e7"
Archived-At: <https://www.postgresql.org/message-id/CABvPt_zjW7oVeYg9SMtYre0cG_Jm_mxPiErZMvf2Eco-hOcDxA%40mail.gmail.com>
Precedence: bulk

--0000000000006350d80624fdf4e7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tom, thanks for your reply!

I understand your point, and also, the idea of embedding postgresql -- it
might be just not what postgresql is built for. I was just thinking that
respecting the standard TZDIR approach would add more flexibility.

If you have 5 linux distros and everyone has a different tzdata location,
it doesn't make much sense to rebuild binaries for each of these distros.
Which means, compile time config is actually the part which adds complexity
-- at least for packaging.

There is no point in having $TZDIR if it's not respected by software. Also,
it feels that setting the filesystem path in compile time just doesn't make
much sense -- it should be a part of runtime configuration.

In my case though, it doesn't block me or anything, -- as you've mentioned,
I can just rebuild without this flag. I was just thinking that supporting
the standard way of timezone configuration would improve the experience of
using postgresql in general and make it more predictive. Maybe it's not
true though due to legacy reasons though -- old users just wouldn't expect
$TZDIR to alter the configuration.


On Mon, Oct 21, 2024 at 4:37=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Anatolii Smolianinov <zarkonesmall@gmail.com> writes:
> > I was recently working with a project which embeds postgres into
> > application. It uses binaries built for Debian, and configured to look
> for
> > timezones in Debian's timezone folder /usr/share/zoneinfo/, which wasn'=
t
> > present on my system.
>
> Why are you trying to use binaries built for Debian on some other
> platform?  Seems like there'd be more problems than just timezones.
>
> > I was thinking if it's possible to redefine it in runtime, and found th=
at
> > it is not possible: postgres support either compilation flag
> > --with-system-tzdata or built-in tz file --  timezone/data/tzdata.zi.
> From
> > the other hand, looking at src/timezone/pgtz.c#L54, it seems that
> timezone
> > dir resolve happens in runtime, which means, it is possible to use $TZD=
IR
> > environment variable or configuration option to achieve this without
> > recompilation.
>
> I'm pretty down on this idea because it adds complexity, ie ways to
> break things.  If you want a more self-contained installation, you
> could build it without specifying --with-system-tzdata.
>
>                         regards, tom lane
>

--0000000000006350d80624fdf4e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Tom, thanks for your reply! <br></div><div><br></d=
iv><div>I understand your point, and also, the idea of embedding postgresql=
 -- it might be just not what postgresql is built for. I was just thinking =
that respecting the standard TZDIR approach would add more flexibility. <br=
></div><div><br></div><div>If you have 5 linux distros and everyone has a d=
ifferent tzdata location, it doesn&#39;t make much sense to rebuild binarie=
s for each of these distros. Which means, compile time config is actually t=
he part which adds complexity -- at least for packaging.=C2=A0</div><div><b=
r></div><div>There is no point in having $TZDIR if it&#39;s not respected b=
y software. Also, it feels that setting the filesystem path in compile time=
 just doesn&#39;t make much sense -- it should be a part of runtime configu=
ration.=C2=A0</div><div><br></div><div>In my case though, it doesn&#39;t bl=
ock me or anything, -- as you&#39;ve mentioned, I can just rebuild without =
this flag. I was just thinking that supporting the standard way of timezone=
 configuration would improve the experience of using postgresql in general =
and make it more predictive. Maybe it&#39;s not true though due to legacy r=
easons though -- old users just wouldn&#39;t expect $TZDIR to alter the con=
figuration. <br></div><div><br></div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 21, 2024 at 4:37=E2=80=AFP=
M Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Anatol=
ii Smolianinov &lt;<a href=3D"mailto:zarkonesmall@gmail.com" target=3D"_bla=
nk">zarkonesmall@gmail.com</a>&gt; writes:<br>
&gt; I was recently working with a project which embeds postgres into<br>
&gt; application. It uses binaries built for Debian, and configured to look=
 for<br>
&gt; timezones in Debian&#39;s timezone folder /usr/share/zoneinfo/, which =
wasn&#39;t<br>
&gt; present on my system.<br>
<br>
Why are you trying to use binaries built for Debian on some other<br>
platform?=C2=A0 Seems like there&#39;d be more problems than just timezones=
.<br>
<br>
&gt; I was thinking if it&#39;s possible to redefine it in runtime, and fou=
nd that<br>
&gt; it is not possible: postgres support either compilation flag<br>
&gt; --with-system-tzdata or built-in tz file --=C2=A0 timezone/data/tzdata=
.zi. From<br>
&gt; the other hand, looking at src/timezone/pgtz.c#L54, it seems that time=
zone<br>
&gt; dir resolve happens in runtime, which means, it is possible to use $TZ=
DIR<br>
&gt; environment variable or configuration option to achieve this without<b=
r>
&gt; recompilation.<br>
<br>
I&#39;m pretty down on this idea because it adds complexity, ie ways to<br>
break things.=C2=A0 If you want a more self-contained installation, you<br>
could build it without specifying --with-system-tzdata.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br>
</blockquote></div>

--0000000000006350d80624fdf4e7--