Subject: Re: real/float example for testlibpq3
To: Tom Lane <tgl@sss.pgh.pa.us>,
 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
References: <Yhf70G9OYIKueYZi@workstation-mark-wong>
 <CAExHW5tm1FyoLZXdTjdrfRO7ObuoL_p2krc65C5s8D3eWFB50g@mail.gmail.com>
 <2511609.1646061540@sss.pgh.pa.us>
Cc: Mark Wong <markwkm@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <621D4CF3.6090808@anastigmatix.net>
Date: Mon, 28 Feb 2022 17:30:11 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <2511609.1646061540@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/621D4CF3.6090808%40anastigmatix.net>
Precedence: bulk

On 02/28/22 10:19, Tom Lane wrote:
>> That will standardize the
>> way to fetch real typed values in libpq. That leads to the next
>> question. Do we need to introduce different PQget*value() for standard
>> C/SQL data types.
> 
> ... I do not want to go here.  Where would you stop?  How would you
> deal with cross-machine inconsistencies in integer widths?

This stimulates a question for me.

Not just libpq, but all drivers implemented in whatever language, if they
wish to support binary protocol, depend on knowing what the committed
send/recv wire formats are for whichever types they mean to support.

In the current state of affairs, what's considered the ur-source of that
information?

I have often seen those formats documented in code comments, usually above
the recv function in the .c file for a given adt.

Have we got any more, well, machine-readable collection of that knowledge?

Regards,
-Chap