through PGConnection::addDataType.
I'd be curious why and how the SQLData/typemap is better ?
Yes, we did not implement it. PR's are welcome, but it's a bigger job than it appears at first glance.
I guess it. It seems a huge job even at the first glance, especially after I walked through the PGObject (and some reference gis-related subclasses) implementation. Maybe in the future, someday... cause it is really way simpler to use.
For example, the type I’ve mentioned before, CREATE TYPE MYTYPE2 AS (a TEXT, b TEXT), would be bound to Java with something as basic as:
@Override
public void readSQL(SQLInput in, String type) throws SQLException {
a = in.readString();
b = in.readString();
}
@Override
public void writeSQL(SQLOutput out) throws SQLException {
out.writeString(a);
out.writeString(b);
}
But well, for now what I’ve found seems sufficient at least for me. I’ll think about an article on this, maybe, so some people trying to find out anything on how to subclass PGObject, will at least find something.
And the serialization-deserialization helpers like I’ve mentioned above could be good to have maybe in the official code; like, even in Utils class.
(For future readers:)
I seem to have get some success with the getValue() implementation.
The general procedure to escape strings is like this:
Do NOT use the Utils.escapeLiteral() (what is the first idea that comes to the mind). Instead, do the following:
if the incoming object is null, the result string (token) should have an empty string ("").
Otherwise, replace each double-quote with two double-quotes; replace each backslash with two backslashes; surround it with double quotes.
Nice! I’ve seen it whenever I wrote any PL/PgSQL code, but haven’t guessed out it could be used here as well. It will add some overhead for the delimiters, but well, it could be a good improvement and basically easier.
And what about my other escaping-deescaping code? Does it look safe and reasonable, or I may be missing something else?
