public inbox for [email protected]  
help / color / mirror / Atom feed
From: Chapman Flack <[email protected]>
To: Tom Lane <[email protected]>
To: Ashutosh Bapat <[email protected]>
Cc: Mark Wong <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: real/float example for testlibpq3
Date: Mon, 28 Feb 2022 17:30:11 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <Yhf70G9OYIKueYZi@workstation-mark-wong>
	<CAExHW5tm1FyoLZXdTjdrfRO7ObuoL_p2krc65C5s8D3eWFB50g@mail.gmail.com>
	<[email protected]>

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






view thread (16+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: real/float example for testlibpq3
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox