| From: | Dave Cramer <davecramer(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Binary support for pgoutput plugin |
| Date: | 2019-06-04 22:32:23 |
| Message-ID: | CADK3HH+XO3_VRc78x9kibveMm8nQuJeFwXOx1UR-tRn65hNzSQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 4 Jun 2019 at 18:08, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi,
>
> On 2019-06-05 00:05:02 +0200, David Fetter wrote:
> > Would it make sense to work toward a binary format that's not
> > architecture-specific? I recall from COPY that our binary format is
> > not standardized across, for example, big- and little-endian machines.
>
> I think you recall wrongly. It's obviously possible that we have bugs
> around this, but output/input routines are supposed to handle a
> endianess independent format. That usually means that you have to do
> endianess conversions, but that doesn't make it non-standardized.
>
Additionally there are a number of drivers that already know how to handle
our binary types.
I don't really think there's a win here. I also want to keep the changes
small .
Dave
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2019-06-04 22:49:59 | Re: Sort support for macaddr8 |
| Previous Message | Tomas Vondra | 2019-06-04 22:31:11 | Re: Avoiding hash join batch explosions with extreme skew and weird stats |