KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
> Some of the test fails contains minor differences from expected results, like:
> | SELECT '' AS "xxx", *
> | FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
> | xxx | a | b | c | d
> | -----+---+---+------+---
> | - | 0 | | zero |
> | | 2 | 3 | two | 2
> | | 4 | 1 | four | 2
> | + | 0 | | zero |
> | (3 rows)
Yeah, I remember those. What needs to be looked at here is *why* the
output is changing. For a patch that allegedly does not touch the
planner, it's fairly disturbing that you don't get the same results.
> and, some of them are trivial ones, like:
> | SELECT p1.oid, p1.typname
> | FROM pg_type as p1
> | WHERE p1.typtype in ('b','e') AND p1.typname NOT LIKE E'\\_%' AND NOT EXISTS
> | (SELECT 1 FROM pg_type as p2
> | WHERE p2.typname = ('_' || p1.typname)::name AND
> | p2.typelem = p1.oid and p1.typarray = p2.oid);
> | - oid | typname
> | ------+---------
> | - 210 | smgr
> | - 705 | unknown
> | -(2 rows)
> | + oid | typname
> | +------+----------------
> | + 210 | smgr
> | + 705 | unknown
> | + 3403 | security_label
> | +(3 rows)
Are you sure that the security_label type should not have an array type?
I do not offhand see a good argument for that. If it really shouldn't,
we can change the expected output here, but you've got to make that
case first.
regards, tom lane