Come to think of it, we really do need some refactoring in
parse_coerce.c.  I just realized what CVS HEAD's RI code
does with array types:

regression=# create table aa (f1 int[] primary key);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "aa_pkey" for 
table "aa"
regression=# create table bb (b1 real[] references aa);
regression=# insert into bb values('{1,1}');
ERROR:  operator does not exist: integer[] pg_catalog.= real[]

It should have rejected the FK constraint right off the bat, but the
test in ATAddForeignKeyConstraint is effectively just "does real[]
coerce to anyarray" which is not good enough in this context.  Your
patch will have the same misbehavior: it'll allow an FK reference to a
different enum type to be declared, but then fail at runtime.

So it seems neither can_coerce_type() nor find_coercion_pathway() are
really particularly well thought out in terms of what they test or don't
test.  I'm not very sure what a good refactoring would look like,
but I am sure that I don't want all their call sites having to
individually account for ANYfoo types.  Any thoughts?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to