-
Notifications
You must be signed in to change notification settings - Fork 77
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Clunky but serviceable way to set byte order.
Addresses issue #98. There really hasn't been a document that just lays out in detail how PL/Java's data coercions are chosen and especially how the raw-chunk-based versions of SQLInput/SQLOutput work. Discovered, while documenting that, the reason Point was showing bogus values (noted in pull request #59 comments) ... byte order ... leading to a last-minute rework of SQLInputFromChunk and SQLOutputToChunk allowing byte order to be selected. (It has to be selectable, not just fixed, in case PL/Java gets updated at a site that has a bunch of data stored under the old byte order. A switch allows dumping with the old order, then reloading with the new. In fact, by choosing a different byte order for each conversion direction, it is possible ... carefully ... to update in place.) A flag is passed to SQLInputFromChunk_create and SQLOutputFromChunk_create to indicate whether the type is a 'java-based scalar' (otherwise, it is a non-composite mirror), and this allows byte order to be specified separately for scalars and mirrors: historically, it was always bigendian regardless of architecture. Presumably that has never mattered much for java-based scalars (because PostgreSQL itself doesn't have any independent way of seeing into them, so no inconsistency was visible), but for a mirror type it is definitely broken if the hardware is not bigendian, with PostgreSQL and Java not seeing the values the same way. Therefore, this change leaves the scalar default (for 1.5.0 at least) at bigendian, in case some sites may have used Java-based scalars in the past and have tables that contain them. Also, the current UDT implementation gives every scalar type a binary send/receive/COPY format that can't (yet) be decoupled from its internal stored form, and the PostgreSQL docs specify big-endian for those binary transfer formats, so it would be premature to change the scalar byte-order default before it is also possible to have a separate transfer format. For mirror types, on the other hand, the default is here immediately changed to native ... it is less likely that sites were heavily using mirror UDTs if they were seeing bogus values, and this will make them work right by default. Java properties are used (set with -D in the pljava.vmoptions GUC): org.postgresql.pljava.udt.byteorder to set everything the same, org.postgresql.pljava.udt.byteorder.scalar org.postgresql.pljava.udt.byteorder.mirror to set them separately. The allowable values for each property are big_endian, little_endian, and native. Even finer-grained control is available with: org.postgresql.pljava.udt.byteorder.scalar.p2j org.postgresql.pljava.udt.byteorder.scalar.j2p org.postgresql.pljava.udt.byteorder.mirror.p2j org.postgresql.pljava.udt.byteorder.mirror.j2p for a very special purpose, should someone wish to attempt an UPDATE where within a session, a column with values written in one order gets rewritten in another, a fiddly and somewhat unnerving process that turns out to actually work, and has a full new page documenting it now.
- Loading branch information
Showing
15 changed files
with
921 additions
and
13 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.