Re: Regarding useObjects

On 9/27/23 13:17, Dave Cramer wrote:
>
>
> On Wed, 27 Sept 2023 at 06:07, Achilleas Mantzios - cloud
> <a(dot)mantzios(at)cloud(dot)gatewaynet(dot)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* 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
>>