Resolve inconsistent result issue in gpdtm_plpgsql test case (#491)

Fix #478

Change logs
ICW testcase gpdtm_plpgsql failed intermittently. The result of the following statements is not consistent.

CREATE TABLE test_parse_arr (a bigserial, b int[]);
-- parse_arr function is defined as a udf to convert string into in array, but it is not important to this issue
INSERT INTO test_parse_arr (b)
        SELECT parse_arr(x) as pr FROM
                                (
                                  SELECT '(1, 2, 3)' AS x
                                  UNION ALL
                                  SELECT NULL
                                  UNION ALL
                                  SELECT '(4, 5, 6)' AS x
                                ) AS q order by pr ;

SELECT * FROM test_parse_arr ORDER BY a;
Here are results from two separate executions.

 a |     b     
---+-----------
 1 | {{4,5,6}}
 2 | {{1,2,3}}
 3 | 
(3 rows)
 a |     b     
---+-----------
 1 | 
 2 | {{1,2,3}}
 3 | {{4,5,6}}
(3 rows)
It is not a cbdb bug. Even though the ORDER BY clause in the INSERT statement ensures the elements in array b are ordered, due to data distribution mechanics—where data is dispatched to different nodes for processing — the sequential generation of auto-increment values(for column a) across these nodes cannot be consistently guaranteed.

Consequently, when querying "SELECT * FROM test_parse_arr ORDER BY a" the resulting sequence may not reflect the initial order of the array elements as they were inserted.

The test case need to be modified to make sure test result consistent.

Instead of verifying result via "SELECT * FROM test_parse_arr ORDER BY a" , verify column a and b separately as following:

SELECT a FROM test_parse_arr ORDER BY a;
SELECT b FROM test_parse_arr ORDER BY b;

src/test/regress/expected/gpdtm_plpgsql.out

@@ -536,18 +536,30 @@ CREATE TABLE test_parse_arr (a bigserial, b int[]);
 NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'a' as the Cloudberry Database data distribution key for this table.
 HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.
 INSERT INTO test_parse_arr (b)
-	SELECT parse_arr(x) FROM 
-				(    
-				  SELECT '(1, 2, 3)' AS x 
-				  UNION ALL
-				  SELECT NULL 
-				) AS q;
-SELECT * FROM test_parse_arr ORDER BY a;
- a |     b     
----+-----------
- 1 | {{1,2,3}}
- 2 | 
-(2 rows)
+        SELECT parse_arr(x) FROM
+                                (
+                                  SELECT '(1, 2, 3)' AS x
+                                  UNION ALL
+                                  SELECT NULL AS x
+                                  UNION ALL
+                                  SELECT '(4, 5, 6)' AS x
+                                  ORDER BY x
+                                ) AS q;
+SELECT a FROM test_parse_arr ORDER BY a;
+ a 
+---
+ 1
+ 2
+ 3
+(3 rows)
+
+SELECT b FROM test_parse_arr ORDER BY b;
+     b     
+-----------
+ {{1,2,3}}
+ {{4,5,6}}
+
+(3 rows)
 
 --
 -- Test if sequence server information outlives a plpgsql exception and corresponding subtransaction rollback (MPP-25193)

src/test/regress/sql/gpdtm_plpgsql.sql

@@ -302,14 +302,19 @@ $dbvis$ LANGUAGE plpgsql;
 CREATE TABLE test_parse_arr (a bigserial, b int[]);
 
 INSERT INTO test_parse_arr (b)
-	SELECT parse_arr(x) FROM 
-				(    
-				  SELECT '(1, 2, 3)' AS x 
-				  UNION ALL
-				  SELECT NULL 
-				) AS q;
-
-SELECT * FROM test_parse_arr ORDER BY a;
+        SELECT parse_arr(x) FROM
+                                (
+                                  SELECT '(1, 2, 3)' AS x
+                                  UNION ALL
+                                  SELECT NULL AS x
+                                  UNION ALL
+                                  SELECT '(4, 5, 6)' AS x
+                                  ORDER BY x
+                                ) AS q;
+
+SELECT a FROM test_parse_arr ORDER BY a;
+
+SELECT b FROM test_parse_arr ORDER BY b;
 
 --
 -- Test if sequence server information outlives a plpgsql exception and corresponding subtransaction rollback (MPP-25193)