Re: About the stability of COPY BINARY data
От | Adrian Klaver |
---|---|
Тема | Re: About the stability of COPY BINARY data |
Дата | |
Msg-id | 32fa25b0-7e5e-40d2-b3a8-e1cd1dbd833d@aklaver.com обсуждение исходный текст |
Ответ на | About the stability of COPY BINARY data (Dominique Devienne <ddevienne@gmail.com>) |
Ответы |
Re: About the stability of COPY BINARY data
|
Список | pgsql-general |
On 11/6/24 08:20, Dominique Devienne wrote: >>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. If I where to hazard a guess this plays a part: https://www.postgresql.org/docs/current/sql-copy.html "To determine the appropriate binary format for the actual tuple data you should consult the PostgreSQL source, in particular the *send and *recv functions for each column's data type (typically these functions are found in the src/backend/utils/adt/ directory of the source distribution)." > > Thanks for any insights, --DD > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: