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

Good Day Vladimir

On 9/27/23 09:03, Vladimir Sitnikov wrote:
>> so there was the option to change this to false and recompile
> We try doing our best to keep backward compatibility both
> compilation-wise and behaviour-wise.
> However, we treat "private fields and methods" as private, a= nd we do
> not expect people would depend on them.
> If you have to modify sources or depend on private APIs I would
> suggest raising an issue or PR so it could be incorporated
> into the driver itself.
>
> Would you please provide a test case of what you are doing with PgArra= y?
> What is exactly the sequence of JDBC calls, the actual and the
> expected outcomes in your case?

E.g. for the case of floats, we have to change all:

java.sql.Array arr =3D rs.getArray(1);

Object objarr =3D arr.getArray();

float flarr[] =3D (float[]) objarr;

to

java.sql.Array arr =3D rs.getArray(1);

Object objarr =3D arr.getArray();

Float flarr[] =3D (Float[]) objarr;

So the problem with using float instead of Float is that it is = impossible to have a null float and arrays can have nulls.

Dave=C2=A0

>
> The mentioned "useObjects" has been removed in
> https://github.com/pgjdbc/pgjdbc/pull/1194 (Refac= tor decoding arrays)
>
> Vladimir

--000000000000a096a60606540b21-- From sitnikov.vladimir@gmail.com Fri Jul 3 22:27:48 2026 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 1qlRGt-002n0y-E5 for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 09:55:55 +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 1qlRGs-002fL9-2T for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 09:55: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 1qlRGr-002fKs-PY for pgsql-jdbc@lists.postgresql.org; Wed, 27 Sep 2023 09:55:53 +0000 Received: from mail-vk1-xa2d.google.com ([2607:f8b0:4864:20::a2d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qlRGk-006uEB-W0 for pgsql-jdbc@postgresql.org; Wed, 27 Sep 2023 09:55:52 +0000 Received: by mail-vk1-xa2d.google.com with SMTP id 71dfb90a1353d-48feedb90d2so3725335e0c.1 for ; Wed, 27 Sep 2023 02:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695808546; x=1696413346; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=enATh++zg82xBcdcNNaBIgUJAdAe9r9AidCmT9fiU0U=; b=iZGbq2F9cCSr4OFaMKl15CWn3BPGiW76D+ilm0BPJdqVi0gVqxsPyX9at97kr99Sru xGfsrbho8TuSzwQf2nZD2eNdePE4SSmMg5LsR1O646Gl0EeqZG7nWMFZYZLf82YwGv1D GlpiHCwfzwJ9atFRpzm00uRCptl+udUZ2qHyCZaVtvR1GD5Cd2cWi4gfhpbbTj3Xbsyi d891h6Z5dnNajDdDyfi8jk2SPedYV0HrUiJIIwCqNtKEp+gmM08rKQTA5T5GhIwW802h /v8EIM13xXpcF5bShdgsjqyUIxVYrHW4QK3kx2wfEs2DfjCCO5RCen9djeyL+ZD/BreF VWPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695808546; x=1696413346; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=enATh++zg82xBcdcNNaBIgUJAdAe9r9AidCmT9fiU0U=; b=fqnBu8oHCEjiIUw2l3Yd2Gq9AE9ShOhPw5axXr4+dVG09YGWEQEkz/HRE2hELvEsL3 c+H5y/8LKxhebl71SjTKHh/arl7V783jLemKSpRBTZ6LmBa+EjEWF1wOhGstqxwIMDEk 2yN427Ivcj/0RzHDOXzB3+PHKBlUW60zA9XagYllLH9hhceFMXFEBiYZua6KBMb3fek2 IXTd1OWe8eJtrHUlq+rOWJnd0WtGx8qdpk3nBq5RO9sN76NTzl8PLJmZySjg/Jzv6gMQ OV2FZlySy9XMZgqrOhHqsW+akH7fznVIlyZLedMdrEJaKRIRxhc6k+Tz2DPHPpUjLjRm CPaA== X-Gm-Message-State: AOJu0YyK0v/iA05vt8aJp/Pg4jmXVGVno7mIciFnbtiomq+vgVUIcY0H AkCVa+wixfGYy5udCa/RPgM7UOmH3BSheavjnu6KsJ48KtY= X-Google-Smtp-Source: AGHT+IGLuEZvvRadu/djK9/P0C+YMduB9DF1zKlc01ES8bHvRLK/5MQaxC9jO4GNf0686X16Wnm9oSTPFFLtz0rknFA= X-Received: by 2002:a1f:6283:0:b0:49a:1605:ee6a with SMTP id w125-20020a1f6283000000b0049a1605ee6amr1510151vkb.5.1695808546040; Wed, 27 Sep 2023 02:55:46 -0700 (PDT) MIME-Version: 1.0 References:

<8d8ea6c9-85a6-d1b8-309d-b1f5bc590840@cloud.gatewaynet.com> In-Reply-To: From: Vladimir Sitnikov Date: Wed, 27 Sep 2023 12:55:35 +0300 Message-ID: Subject: Re: Regarding useObjects To: Dave Cramer , Achilleas Mantzios - cloud Cc: pgsql-jdbc@postgresql.org Content-Type: multipart/alternative; boundary="000000000000fe6fd70606543151" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000fe6fd70606543151 Content-Type: text/plain; charset="UTF-8" > 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 Vladimir --000000000000fe6fd70606543151 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> 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 primiti= ve arrays: https:/= /github.com/pgjdbc/pgjdbc/issues/2939

Vladimir

--000000000000fe6fd70606543151-- From a.mantzios@cloud.gatewaynet.com Fri Jul 3 22:27:48 2026 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 1qlRL7-002nFh-8G for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:00:17 +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 1qlRL5-002hX5-TW for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:00:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlRL5-002hWi-LW for pgsql-jdbc@lists.postgresql.org; Wed, 27 Sep 2023 10:00:15 +0000 Received: from cloud.gatewaynet.com ([185.90.37.94]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlRL2-007rwq-A9 for pgsql-jdbc@postgresql.org; Wed, 27 Sep 2023 10:00:15 +0000 Content-Type: multipart/alternative; boundary="------------Mljf64FxlMAFjH86MLsve15N" Message-ID: <405c32b4-4b39-b961-010c-93386e7f7ac4@cloud.gatewaynet.com> Date: Wed, 27 Sep 2023 13:00:09 +0300 MIME-Version: 1.0 Subject: Re: Regarding useObjects Content-Language: en-US To: Dave Cramer Cc: Vladimir Sitnikov , pgsql-jdbc@postgresql.org References:

<8d8ea6c9-85a6-d1b8-309d-b1f5bc590840@cloud.gatewaynet.com> From: Achilleas Mantzios - cloud In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------Mljf64FxlMAFjH86MLsve15N Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/27/23 12:44, Dave Cramer wrote: > > > On Wed, 27 Sept 2023 at 05:00, Achilleas Mantzios - cloud > wrote: > > Good Day Vladimir > > On 9/27/23 09:03, Vladimir Sitnikov wrote: > >> so there was the option to change this to false and recompile > > We try doing our best to keep backward compatibility both > > compilation-wise and behaviour-wise. > > However, we treat "private fields and methods" as private, and we do > > not expect people would depend on them. > > If you have to modify sources or depend on private APIs I would > > suggest raising an issue or PR so it could be incorporated > > into the driver itself. > > > > Would you please provide a test case of what you are doing with > PgArray? > > What is exactly the sequence of JDBC calls, the actual and the > > expected outcomes in your case? > > E.g. for the case of floats, we have to change all: > > java.sql.Array arr = rs.getArray(1); > > Object objarr = arr.getArray(); > > float flarr[] = (float[]) objarr; > > to > > java.sql.Array arr = rs.getArray(1); > > Object objarr = arr.getArray(); > > Float flarr[] = (Float[]) objarr; > > > > So the problem with using float instead of Float is that it is > impossible to have a null float and arrays can have nulls. Thanks Dave, we wrote much of the code before 2008, and we had to implement our own version of nulls in arrays of primitives. So this code was stuck everywhere. Plus we got like 120+ remote sites (slaves) ( which run ... even older code) so we must fully support them as well. Its only about 200 source files in the central system's repo, so we will have to do it sooner or later. The hard part would be migrating from pgsql 10 to 16. > > Dave > > > > > > The mentioned "useObjects" has been removed in > > https://github.com/pgjdbc/pgjdbc/pull/1194 (Refactor decoding > arrays) > > > > Vladimir > > --------------Mljf64FxlMAFjH86MLsve15N Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 9/27/23 12:44, Dave Cramer wrote:

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

Good Day Vladimir

On 9/27/23 09:03, Vladimir Sitnikov wrote:
>> so there was the option to change this to false and recompile
> We try doing our best to keep backward compatibility both
> compilation-wise and behaviour-wise.
> However, we treat "private fields and methods" as private, and we do
> not expect people would depend on them.
> If you have to modify sources or depend on private APIs I would
> suggest raising an issue or PR so it could be incorporated
> into the driver itself.
>
> Would you please provide a test case of what you are doing with PgArray?
> What is exactly the sequence of JDBC calls, the actual and the
> expected outcomes in your case?

E.g. for the case of floats, we have to change all:

java.sql.Array arr = rs.getArray(1);

Object objarr = arr.getArray();

float flarr[] = (float[]) objarr;

to

java.sql.Array arr = rs.getArray(1);

Object objarr = arr.getArray();

Float flarr[] = (Float[]) objarr;

So the problem with using float instead of Float is that it is impossible to have a null float and arrays can have nulls.

Thanks Dave, we wrote much of the code before 2008, and we had to implement our own version of nulls in arrays of primitives. So this code was stuck everywhere. Plus we got like 120+ remote sites (slaves) ( which run ... even older code) so we must fully support them as well. Its only about 200 source files in the central system's repo, so we will have to do it sooner or later.

The hard part would be migrating from pgsql 10 to 16.

Dave

>
> The mentioned "useObjects" has been removed in
> https://github.com/pgjdbc/pgjdbc/pull/1194 (Refactor decoding arrays)
>
> Vladimir

--------------Mljf64FxlMAFjH86MLsve15N-- From a.mantzios@cloud.gatewaynet.com Fri Jul 3 22:27:48 2026 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 1qlRSM-002nn2-Iw for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:07:46 +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 1qlRSL-002mKt-8X for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:07:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlRSL-002mKX-0V for pgsql-jdbc@lists.postgresql.org; Wed, 27 Sep 2023 10:07:45 +0000 Received: from cloud.gatewaynet.com ([185.90.37.94]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlRSH-007s0I-UT for pgsql-jdbc@postgresql.org; Wed, 27 Sep 2023 10:07:44 +0000 Content-Type: multipart/alternative; boundary="------------M2SWLnkNLwOf3TMVSt4Rzdk4" Message-ID: Date: Wed, 27 Sep 2023 13:07:39 +0300 MIME-Version: 1.0 Subject: Re: Regarding useObjects Content-Language: en-US To: Vladimir Sitnikov , Dave Cramer Cc: pgsql-jdbc@postgresql.org References:

<8d8ea6c9-85a6-d1b8-309d-b1f5bc590840@cloud.gatewaynet.com>

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.

Vladimir

--------------M2SWLnkNLwOf3TMVSt4Rzdk4-- From davecramer@postgres.rocks Fri Jul 3 22:27:48 2026 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 1qlRcI-002oTs-7B for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:18:02 +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 1qlRcG-002r3G-5v for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:18:00 +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 1qlRcF-002r2t-UG for pgsql-jdbc@lists.postgresql.org; Wed, 27 Sep 2023 10:17:59 +0000 Received: from pgintl.fastcrypt.com ([149.56.129.164]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qlRcD-006uPN-DO for pgsql-jdbc@postgresql.org; Wed, 27 Sep 2023 10:17:58 +0000 Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by pgintl.fastcrypt.com (Postfix) with ESMTPSA id 384DC201A1 for ; Wed, 27 Sep 2023 06:17:56 -0400 (EDT) Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2c12ae20a5cso174387721fa.2 for ; Wed, 27 Sep 2023 03:17:56 -0700 (PDT) X-Gm-Message-State: AOJu0YxD3u2iDW6dIV5ixBwQTXkiC9jw8RRb8VYlqnlH9THcvcZS5T5A 5DnTrJWMMunQsBM4LFVdGaJgA8fvpP+xLwkqPYw= X-Google-Smtp-Source: AGHT+IHJTnIDdnKxP5UZKQ9JGxLYvgXHDjeJyIbjJUI11Zt4PbC5/jQIGpbuVvoab2uh6tukyUjOL/FO96d60QpNKi4= X-Received: by 2002:a2e:9c53:0:b0:2bf:7894:a490 with SMTP id t19-20020a2e9c53000000b002bf7894a490mr1586219ljj.38.1695809874548; Wed, 27 Sep 2023 03:17:54 -0700 (PDT) MIME-Version: 1.0 References:

<8d8ea6c9-85a6-d1b8-309d-b1f5bc590840@cloud.gatewaynet.com>

In-Reply-To: From: Dave Cramer Date: Wed, 27 Sep 2023 06:17:37 -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="0000000000002ddd9006065481f6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002ddd9006065481f6 Content-Type: text/plain; charset="UTF-8" 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 ? Dave > > Vladimir > > --0000000000002ddd9006065481f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

=20 =20 =20

On 9/27/23 12:55, Vladimir Sitnikov wrote:

=20

> 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: http= s://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.= =C2=A0

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

D= ave

Vladimir

--0000000000002ddd9006065481f6-- From a.mantzios@cloud.gatewaynet.com Fri Jul 3 22:27:48 2026 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 1qlRmp-002p7S-Qt for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:28:55 +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 1qlRmo-002uXI-CC for pgsql-jdbc@arkaria.postgresql.org; Wed, 27 Sep 2023 10:28: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 1qlRmn-002uX3-W9 for pgsql-jdbc@lists.postgresql.org; Wed, 27 Sep 2023 10:28:54 +0000 Received: from cloud.gatewaynet.com ([185.90.37.94]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlRmg-006uTM-GT for pgsql-jdbc@postgresql.org; Wed, 27 Sep 2023 10:28:52 +0000 Content-Type: multipart/alternative; boundary="------------a5JhFKxg3OxnKAczeD2kpboC" Message-ID: <702e914b-6a09-6176-83b3-471a13076d5e@cloud.gatewaynet.com> Date: Wed, 27 Sep 2023 13:28:42 +0300 MIME-Version: 1.0 Subject: Re: Regarding useObjects Content-Language: en-US To: Dave Cramer Cc: Vladimir Sitnikov , pgsql-jdbc@postgresql.org References:

<8d8ea6c9-85a6-d1b8-309d-b1f5bc590840@cloud.gatewaynet.com>

From: Achilleas Mantzios - cloud In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------a5JhFKxg3OxnKAczeD2kpboC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 9/27/23 13:17, Dave Cramer wrote: > > > On Wed, 27 Sept 2023 at 06:07, Achilleas Mantzios - cloud > 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* dayswe 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). > > Dave > >> >> Vladimir >> --------------a5JhFKxg3OxnKAczeD2kpboC Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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).

Dave

Vladimir

--------------a5JhFKxg3OxnKAczeD2kpboC-- From davecramer@postgres.rocks Fri Jul 3 22:27:48 2026 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