Re: [PATCH v1] Fix parsing of a complex type that has an array of complex types - Mailing list pgsql-hackers

From Arjan Marku
Subject Re: [PATCH v1] Fix parsing of a complex type that has an array of complex types
Date
Msg-id 8006b0e5-2a45-4354-a58f-088c8266d9ed@gmail.com
Whole thread Raw
In response to Re: [PATCH v1] Fix parsing of a complex type that has an array of complex types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

I agree with all your points as I encountered them myself, especially ambiguity and error handling.

The introduced dependency between those functions also is for me a bad idea but it seemed like the only way to support that use case, but turns out my assumption that the array literal shouldn't be quoted was wrong,

I managed to execute this query fine:
INSERT INTO item_2d_table VALUES(1, '(1,"{{""(\\""inv a\\"",42,1.99)"",""(\\"inv b\\",42,1.99)""},{""(\\""inv c\\"",42,1.99)"",""(\\""inv d\\"",42,2)""}}")');

Thanks for your insights on this,

Kind regards,
Arjan Marku

On 7/15/24 9:15 PM, Tom Lane wrote:
INSERT INTO item_2d_table VALUES(1, '(1,{{("inv a",42,1.99),("inv 
b",42,1.99)},{("inv c",42,1.99),("inv d",42,2)}})');

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Converting tab-complete.c's else-if chain to a switch
Next
From: Robert Haas
Date:
Subject: Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal