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. I'm having trouble coming
up with a good name for the reverse of that, off the top of my head.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com