On 12/6/23 10:32, Andrew Dunstan wrote:
On 2023-12-06 We 08:49, Joe Conway wrote:
On 12/6/23 07:36, Andrew Dunstan wrote:
On 2023-12-05 Tu 16:46, Joe Conway wrote:
On 12/5/23 16:20, Andrew Dunstan wrote:
On 2023-12-05 Tu 16:09, Joe Conway wrote:
On 12/5/23 16:02, Joe Conway wrote:
On 12/5/23 15:55, Andrew Dunstan wrote:
and in any other case (e.g. LINES) I can't see why you
would have them.
Oh I didn't address this -- I saw examples in the interwebs of
MSSQL server I think [1] which had the non-array with commas
import and export style. It was not that tough to support and the
code as written already does it, so why not?
That seems quite absurd, TBH. I know we've catered for some
absurdity in
the CSV code (much of it down to me), so maybe we need to be
liberal in
what we accept here too. IMNSHO, we should produce either a single
JSON
document (the ARRAY case) or a series of JSON documents, one per row
(the LINES case).
So your preference would be to not allow the non-array-with-commas
case but if/when we implement COPY FROM we would accept that format?
As in Postel'a law ("be conservative in what you do, be liberal in
what you accept from others")?
Yes, I think so.
Awesome. The attached does it that way. I also ran pgindent.
I believe this is ready to commit unless there are further comments or
objections.
Sorry to bikeshed a little more, I'm a bit late looking at this.
I suspect that most users will actually want the table as a single JSON
document, so it should probably be the default. In any case FORCE_ARRAY
as an option has a slightly wrong feel to it.
Sure, I can make that happen, although I figured that for the
many-rows-scenario the single array size might be an issue for whatever
you are importing into.
I'm having trouble coming up with a good name for the reverse of
that, off the top of my head.
Will think about it and propose something with the next patch revision.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
