From: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | About the stability of COPY BINARY data |
Date: | 2024-11-06 16:20:12 |
Message-ID: | CAFCRh-9W8mXh9MfRe-Z5bAcN5FVbsXuSW60-QPVMB1jHC4+bzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
From https://www.postgresql.org/docs/current/sql-copy.html:
|> binary-format file is less portable across machine architectures
and PostgreSQL versions
In my experience, the binary encoding of binding/resultset/copy is
endian neutral (network byte order), so what is the less portable
across machine architectures that warning about?
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?
The binary data contains OIDs, but if sticking to built-in types,
which OIDs are unlikely to change across versions?
I'm obviously storing COPY BINARY data (we have lots of bytea
columns), and I wonder how bad it is long term, and across PostgreSQL
versions.
Thanks for any insights, --DD
From | Date | Subject | |
---|---|---|---|
Next Message | Ramakrishna m | 2024-11-06 17:13:46 | Performance Issue with Hash Partition Query Execution in PostgreSQL 16 |
Previous Message | David Rowley | 2024-11-05 23:38:00 | Re: Why not do distinct before SetOp |