From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | Ilya Gladyshev <ilya(dot)v(dot)gladyshev(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: postgres_fdw binary protocol support |
Date: | 2022-11-23 19:23:45 |
Message-ID: | CAM-w4HPXWYPM7zLfwcHO4KuBb3ZGX7KXiAA0EPzZthvNcBdQhg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 22 Nov 2022 at 08:17, Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> AFAIU, binary compatibility of two postgresql servers depends upon the
> binary compatibility of the platforms on which they run.
No, libpq binary mode is not architecture-specific. I think you're
thinking of on-disk binary compatibility. But libpq binary mode is
just a binary network representation of the data instead of an ascii
representation. It should be faster and more efficient but it still
goes through binary input/output functions (which aren't named
input/output)
I actually wonder if having this would be a good way to get some code
coverage of the binary input/output functions which I suspect is sadly
lacking now. It wouldn't necessarily test that they're doing what
they're supposed to... but at least they would be getting run which I
don't think they are currently?
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2022-11-23 19:28:14 | Re: fixing CREATEROLE |
Previous Message | Tomas Vondra | 2022-11-23 19:08:46 | Re: Hash index build performance tweak from sorting |