-
Notifications
You must be signed in to change notification settings - Fork 860
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
java.sql.Struct type support #381
Comments
I would also like to add that this makes it nearly impossible to support custom types when using PGJDBC with most connection poolers, especially HikariCP, which does not offer an interface to access the real connection object (needed to inform PGJDBC of a custom PGobject). |
@RomanHargrave , are you sure HikariCP does not allow to access PGConnection? According to brettwooldridge/HikariCP#85
The tricky part there is
I've already tried to tackle this problem and I do not see an elegant way of solving that. If you have some time, it would be nice if you could share your thoughts. |
I am aware of this, unfortunately my current SQL stack only supports initializing the connection pooler and providing it the the query abstraction layer (I could easily change this, I suppose). That being said, it would be better if some manner of pluggable factory were supported by the pooler spec, but alas, this is not in any way related to PGJDBC. I solved my issue simply by taking the simple implementation of PGobject returned by PG for types it does not have a PGobject registered for and then converting it. I do not plan to perform a large amount of transactions involving this type in the application using PGJDBC, so the extra step is no issue. That being said, I can see how the problems you mentioned would be roadblocks to implementing Struct support. My need for Struct came primarily out of some frustration with implementing a Java/Scala representation of a composite type. Due to the predictable nature of composite type literals, PGobject could be subclassed to create a composite type object that can programmatically compute a Postgres composite literal from a sequence of member values, and conversely, extract, and assign the strictest applicable type to, member values extracted from a composite literal. As long as this implementation knows the types of the composite's fields in the order that they occur, it should be relatively simple to parse it given that Postgres stringifies composites in the form That being said, while I have some idea of how the driver behaves, I cannot say I know every detail for sure, at least with regards to what values it might hand a PGobect to translate. |
AFAICT Postgres automatically wraps those strings in double quotes. It doesn't wrap strings which don't contain commas though. So you would have to deal with both scenarios. |
anythings update? |
Having to parse and generate Postgres compliant strings is not nice. Please support Struct! |
One of the challenges is that we also have to create the corresponding struct compatible with your code. Is there anything we can do to make it easier for you such as a helper function for compliant strings ? |
I do have working code, so it's not a show stopper for me. But I did struggle to find documentation on how to convert to and from PgObject. Helper functions to convert |
care to share some examples ? even privately |
I am using MyBatis and have written an abstract TypeHandler for custom postgres types as well as another one for arrays of custom types. |
Thanks, I wasn't. But it does not seem to be supported when passing PgObject values:
When I use quotes for each value like this the dollars get included in the value and are not removed
|
Send me a small test case. Pretty sure this should work. |
|
This runs the same insert and reads with 2 different escape functions.
|
So ya, the $ quoting doesn't work like I thought it would. |
@davecramer Could you please explain why the issue was closed? Has it been somehow resolved? Or is it just a "won't fix"? |
I am also curious why the issue closed. Seems like a needed feature. |
basically, it's very difficult with the current codebase. Feel free to create a PR |
It looks like PGJDBC does not support mapping user-defined types by means of
java.sql.Struct
, which seems to me to be the JVM-standard means of defining user types, and is far more orthagonal thanPGObject
, which requires that the user be able to parse object literals.It would be great if Postgres-JDBC were to support using
java.sql.Struct
unless some manner of critical roadblock stands in the way.The text was updated successfully, but these errors were encountered: