Re: About the stability of COPY BINARY data

On Thu, Nov 7, 2024 at 7:04 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
> On 11/7/24 09:55, Dominique Devienne wrote:
> > On Thu, Nov 7, 2024 at 6:39 PM Daniel Verite <daniel(at)manitou-mail(dot)org> wrote:
> >> Dominique Devienne wrote:
> >>> Also, does the code for per-type _send() and _recv() functions
> >>> really change across versions of PostgreSQL? How common are
> >>> instances of such changes across versions? Any examples of such
> >>> backward-incompatible changes, in the past?
> >>
> >> For the timestamp types, I think these functions were
> >> sending/expecting float8 (before version 7.3), and then float8 or
> >> int64 depending on the server configuration up until 9.6, and since
> >> then int64 only.
> >> The same for the "time" field of the interval type.
> >> There is still an "integer_datetimes" GUC reflecting this.
> >
> > Thanks. So it did happen in a distant past.
> > Anything below 14 is of no concern to me though.
> > So again, it does sound like changes are unlikely.
>
> Yeah that is implied by:
>
> https://www.postgresql.org/docs/current/pgupgrade.html
>
> "Major PostgreSQL releases regularly add new features that often change
> the layout of the system tables, but the internal data storage format
> rarely changes. "
>
> The COPY warning is there as heads up that it is a possibility.
> >
> > And I haven't seen anything not network-byte-order,
> > as far architecture is concerned.

But the COPY BINARY format and "the internal data storage format"
are two separate things Adrian, AFAIK.

Using binds and result sets in binary mode is part of the protocol in a way,
and not an internal implementation detail, like internal format for
tables on disk.

I'm sure I'm not the only one that using binary mode for PostgreSQL,
and any change in _send and _recv functions across versions, or have their
results be architecture dependent, would break many client codes, if
it happened.
And COPY BINARY's outer format is also public and documented, so can't
change either.

That's why I'm insisting on that phrase in the documentation, which
gives the wrong impressions IMHO.
Shouldn't it be removed or amended? Thanks, --DD