Re: (How to) Make composite PGObject with Text? (Was: (How to) Make SQLData of UUID?)

Dave Cramer

[email protected]
www.postgresintl.com


On Tue, 23 Jul 2019 at 11:25, Alexander Myodov <[email protected]> wrote:

> Hello,
>
> through PGConnection::addDataType.
>>>>>
>>>> I'd be curious why and how the SQLData/typemap is better ?
>>>>
>>> It seems a part of JDBC standard interfaces, rather clearly defined and
>>> well documented, see an example at
>>> https://docs.oracle.com/javase/tutorial/jdbc/basics/sqlcustommapping.html
>>> .
>>>
>> Yes, we did not implement it. PR's are welcome, but it's a bigger job
>> than it appears at first glance.
>>
>
it's basically the reason the ng driver exists ... :)

>
> 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.
>>>
>>
>> So you may have much easier time using dollar quoting
>> https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING
>>
> 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?
>

Have a look at
https://github.com/postgres/postgres/blob/06140c201b982436974d71e756d7331767a41e57/src/interfaces/libpq/fe-exec.c#L3336
for hints as to what you may or may not be missing.

Dave

>
> --
> Alex Myodov
>