Re: WIP Patch: Add a function that returns binary JSONB as a bytea
От | Merlin Moncure |
---|---|
Тема | Re: WIP Patch: Add a function that returns binary JSONB as a bytea |
Дата | |
Msg-id | CAHyXU0yfb=Nst7CXXzxTv0hOF4Amk6LoS8weZK-CNqG1--OibA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP Patch: Add a function that returns binary JSONB as a bytea (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: WIP Patch: Add a function that returns binary JSONB as a bytea
Re: WIP Patch: Add a function that returns binary JSONB as a bytea Re: WIP Patch: Add a function that returns binary JSONB as a bytea |
Список | pgsql-hackers |
On Wed, Oct 31, 2018 at 10:23 AM Andres Freund <andres@anarazel.de> wrote: > > Hi, > > On 2018-10-31 11:13:13 -0400, Andrew Dunstan wrote: > > I agree that just sending a blob of the internal format isn't a great idea. > > It's entirely unacceptable afaict. Besides the whole "exposing > internals" issue, it's also at least not endianess safe, depends on the > local alignment requirements (which differ both between platforms and > 32/64 bit), numeric's internal encoding and probably more. Binary format consuming applications already have to deal with these kinds of issues. We already expose internal structures in the other functions -- not sure why jsonb is held to a different standard. For other data types where format changes were made, the standard of 'caveat version' was in place to protect the user. For jsonb we decided to implement a version flag within the type itself, which I thought mistake at the time -- better to have a version header in the COPY BINARY if needed. People using binary format are basically interested one one thing, performance. It's really the fastest way to get data in an out of the database. For my part, I'd like to see some observed demonstrable benefit in terms of performance to justify making the change. merlin
В списке pgsql-hackers по дате отправления: