Re: [0/4] Proposal of SE-PostgreSQL patches

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