KaiGai Kohei <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers