Re: [PATCH v1] Fix parsing of a complex type that has an array of complex types

From: Arjan Marku <arjanmarku02(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH v1] Fix parsing of a complex type that has an array of complex types
Date: 2024-07-15 19:59:24
Message-ID: 8006b0e5-2a45-4354-a58f-088c8266d9ed@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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)}})');

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-07-15 20:03:13 Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal
Previous Message Tom Lane 2024-07-15 19:42:40 Re: Converting tab-complete.c's else-if chain to a switch