Somehow I assume that pgAdmin gets internally the binary representation of the double precision value from the reply of the database, and shows it accordingly in a decimal representation on the screen.
No, actually it doesn't grok binary at all. This -0
and 0
are text representations that come verbatim from the server. If pgAdmin understood binary, it could be able to display the result of this SQL sequence:
DECLARE c BINARY CURSOR WITH HOLD FOR
SELECT -0::double precision AS minuszero, 0::double precision AS pluszero;
FETCH 1 FROM c;
and in fact, it displays an empty string as output in each column.
The psql
command line tool is also unable to deal with binary because it doesn't support null bytes in raw query results.
This is not a limitation of the C libpq
library however, even with its simplest function PQexec()
. Raw bytes could be obtained and displayed in hex with this code:
PGresult* res = PQexec(conn, "DECLARE c BINARY CURSOR WITH HOLD FOR "
"SELECT -0::double precision AS minuszero, 0::double precision AS pluszero;"
"FETCH 1 FROM c");
if (res && PQresultStatus(res)==PGRES_TUPLES_OK) {
for (int i=0; i<PQnfields(res); i++) {
printf("column %s: ", PQfname(res, i));
for (int j=0; j<PQfsize(res,0); j++)
printf("%02x", ((unsigned char*)PQgetvalue(res, 0, i))[j]);
printf("\n");
}
}
result:
column minuszero: 8000000000000000
column pluszero: 0000000000000000
You can finally see this sign bit as the first (and only) bit set in the first column. It's in network byte order, MSB first, which is reversed compared to the disk representation for little endian architecture, as used in the x86 family.