Re: Bug in JDBC.driver CopyManager method when copying json output

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, "Gerson(dot)Stadlmann(at)ifco(dot)com" <Gerson(dot)Stadlmann(at)ifco(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Bug in JDBC.driver CopyManager method when copying json output
Date: 2018-10-20 17:16:32
Message-ID: 13326.1540055792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> The backend is respecting the documented meanings and usage of the QUOTE
> and ESCAPE options of COPY.

Yeah, I don't see any bug here. You've got one layer of backslash-quoting
that is required by JSON string syntax, and then a second layer that is
imposed by COPY's text format.

> Not sure what a JSON mode would look like though I’m thinking it’s not what
> was described here...

I can't see how that would do anything except move the pain somewhere
else. Multiple quoting layers always result in "ugly" output (but if
the receipient is correctly coded and reverses the operations in the
right sequence, the same underlying data will emerge).

The OP might want to consider using COPY BINARY, which uses a length
prefix instead of character-escaping to keep fields separate. Still,
though, this is fundamentally just cosmetic. If you don't apply the
correct reverse conversion steps in the correct order, you won't get
the right results.

regards, tom lane

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kalyan Koka 2018-10-22 10:20:41 Stored Procedure call using JDBC is failing
Previous Message Dave Cramer 2018-10-20 15:56:04 Re: ⚠ Re: Bug in JDBC.driver CopyManager method when copying json output