Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlRyS-002puv-CD for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:40:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qlRxS-0031aB-KA for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:39:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlRxS-0031Zr-7e for pgsql-jdbc@lists.postgresql.org; Wed, 27 Sep 2023 10:39:54 +0000 Received: from pgintl.fastcrypt.com ([149.56.129.164]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qlRxL-006uXi-3q for pgsql-jdbc@postgresql.org; Wed, 27 Sep 2023 10:39:53 +0000 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by pgintl.fastcrypt.com (Postfix) with ESMTPSA id 24E292018B for ; Wed, 27 Sep 2023 06:39:45 -0400 (EDT) Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-530bc7c5bc3so13179859a12.1 for ; Wed, 27 Sep 2023 03:39:45 -0700 (PDT) X-Gm-Message-State: AOJu0YzVFoa4epu8U/8vOmOS+LHUoXGDOFckR+6Qz6k8lY31UoznH9nF YZzV2OJzcEcw8qfwmB4KEVz6SY/hZgSChTodmu0= X-Google-Smtp-Source: AGHT+IHuPlSUqdGHpY37XEyCqPawP98NvCjMvWsLtBFUjP+45huGG25V7jVl8daUTBlRG6yuTi2uhyb4NTCS25QBnxs= X-Received: by 2002:aa7:ce11:0:b0:51e:1643:5ad0 with SMTP id d17-20020aa7ce11000000b0051e16435ad0mr1577918edv.8.1695811184927; Wed, 27 Sep 2023 03:39:44 -0700 (PDT) MIME-Version: 1.0 References: <8d8ea6c9-85a6-d1b8-309d-b1f5bc590840@cloud.gatewaynet.com> <702e914b-6a09-6176-83b3-471a13076d5e@cloud.gatewaynet.com> In-Reply-To: <702e914b-6a09-6176-83b3-471a13076d5e@cloud.gatewaynet.com> From: Dave Cramer Date: Wed, 27 Sep 2023 06:39:27 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Regarding useObjects To: Achilleas Mantzios - cloud Cc: Vladimir Sitnikov , pgsql-jdbc@postgresql.org Content-Type: multipart/alternative; boundary="00000000000048ac97060654cf53" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000048ac97060654cf53 Content-Type: text/plain; charset="UTF-8" On Wed, 27 Sept 2023 at 06:28, Achilleas Mantzios - cloud < a.mantzios@cloud.gatewaynet.com> wrote: > > On 9/27/23 13:17, Dave Cramer wrote: > > > > On Wed, 27 Sept 2023 at 06:07, Achilleas Mantzios - cloud < > a.mantzios@cloud.gatewaynet.com> wrote: > >> >> On 9/27/23 12:55, Vladimir Sitnikov wrote: >> >> > So the problem with using float instead of Float is that it is >> impossible to have a null float and arrays can have nulls. >> >> There's a feature request for retrieving primitive arrays: >> https://github.com/pgjdbc/pgjdbc/issues/2939 >> >> back in pre-postgresql-42* days we used to use -888 and -888.888 to >> represent int NULL and float NULL respectively, quite ...primitive but it >> worked. We should retain this old mapping , but once all systems are up to >> date we will start storing and reading NULLs in arrays as NULLs. >> > Using that mapping is not something that we would entertain. > > If you are going to actually store NULL in the array, how would that work > with primitives ? > > We support our central system (master) plus 120 slave systems > communicating via satellites (running very old versions of everything , > linux, postgersql , java, jdbc, etc) using custom replication code (a hack > of DBmirror) that we wrote back in 2003 or so. Data come back and forth, so > we have to support all those 120 archaic slaves while we upgrade and after > we upgrade the central system. > > When everything is up to date, (which will be some years from now), then > we will start actually storing NULLs inside arrays instead of -888 and > -888.888 . BUT even then, we are not willing to update the actual old data > (-888) to the new NULL version, because that would trigger a massive > replication traffic from our central system to the slaves. Also updating > all past / historic values would cause bloating, huge autovacuum activity, > among other things on those remote slaves that run unmanned (in simple > english : I am the only DBA for all 1 + 120 postgresql instances) . So we > should support historic data as they are, until something bigger happens > (like a vast update in our topology/logic/etc). > So it sounds like this would work for you if someone implemented primitive arrays. Dave --00000000000048ac97060654cf53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 27 Sept 2023 at 06:28, Achill= eas Mantzios - cloud <a.mantzios@cloud.gatewaynet.com> wrote:
=20 =20 =20


On 9/27/23 13:17, Dave Cramer wrote:
=20


On Wed, 27 Sept 2023 at 06:07, Achilleas Mantzios - cloud <a.mantzios@cloud.gatewaynet.com= > wrote:


On 9/27/23 12:55, Vladimir Sitnikov wrote:
> So the problem with using float instead of Float is that it is impossible to have a null float and arrays can have nulls.

There's a feature request for retrieving primitive arrays: https://github.com/pgjdbc/pgjdbc/issues/2939<= br>

back in pre-postgresql-42* days<= /span> we used to use -888 and -888.888 to represent int NULL and float NULL respectively, quite ...primitive but it worked. We should retain this old mapping , but once all systems are up to date we will start storing and reading NULLs in arrays as NULLs.

Using that mapping is not something that we would entertain.=C2=A0

If you are going to actually store NULL in the array, how would that work with primitives ?

We support our central system (master) plus 120 slave systems communicating via satellites (running very old versions of everything , linux, postgersql , java, jdbc, etc) using custom replication code (a hack of DBmirror) that we wrote back in 2003 or so. Data come back and forth, so we have to support all those 120 archaic slaves while we upgrade and after we upgrade the central system.

When everything is up to date, (which will be some years from now), then we will start actually storing NULLs inside arrays instead of -888 and -888.888 . BUT even then, we are not willing to update the actual old data (-888) to the new NULL version, because that would trigger a massive replication traffic from our central system to the slaves. Also updating all past / historic values would cause bloating, huge autovacuum activity, among other things on those remote slaves that run unmanned (in simple english : I am the only DBA for all 1 + 120 postgresql instances) . So we should support historic data as they are, until something bigger happens (like a vast update in our topology/logic/etc).

=

So it sounds like this would work for you = if someone implemented primitive arrays.=C2=A0=C2=A0

Dave
--00000000000048ac97060654cf53--