Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: support bytea in preferQueryMode=simple #3243

Merged
merged 1 commit into from May 17, 2024
Merged

Conversation

vlsi
Copy link
Member

@vlsi vlsi commented May 11, 2024

This adds text encoding for bytea.

Interestingly, the tricks with private final char[] hexDigits do not improve performance, and we probably should stick with Character.forDigit(...) for int -> hex conversions.


Unfortunately, we have two different handling of "stream underflow" with StreamWrapper and ByteStreamWriter.

Both of them might report their lengths, and both of them might happen to underflow or overflow.

PGStream handles StreamWrapper as follows (see org.postgresql.core.PGStream#sendStream):

  • If there's not enough data in the stream => raise "Premature end of input stream"
  • If there's too much data => just ignore it

PGStream handles ByteStreamWriter as follows (see org.postgresql.core.PGStream#send(ByteStreamWriter)):

  • If there's not enough data in the stream => append zeros
  • If there's too much data => throw an error

Note: ByteStreamWriter works in a push manner, so we can't easily stop it, so "throwing an error" on overflow might be ok.

However, it is unfortunate we have different behaviours regarding "pad with zeros" vs "throw on underflow". I think we should raise an error on underflow in both cases.

@vlsi vlsi force-pushed the bytea_simple branch 3 times, most recently from ba3456c to ce74cce Compare May 12, 2024 11:46
@vlsi vlsi marked this pull request as ready for review May 12, 2024 11:47
@vlsi
Copy link
Member Author

vlsi commented May 12, 2024

I think this is ready, and I'm going to merge it after some time

@vlsi vlsi merged commit 450488c into pgjdbc:master May 17, 2024
7 of 8 checks passed
@bokken
Copy link
Member

bokken commented May 18, 2024

Did you compare going directly to a byte[] with the ascii bytes rather than using a StringBuilder?

@vlsi
Copy link
Member Author

vlsi commented May 18, 2024

The existing code was building SQL with StringBuilder, so I benchmarked SB only

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants