On 9/27/23 13:17, Dave Cramer 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).