From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tom Dunstan <pgsql(at)tomd(dot)cc>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Matt Miller <pgsql(at)mattmillersf(dot)fastmail(dot)fm>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: "anyelement2" pseudotype |
Date: | 2007-02-15 19:46:44 |
Message-ID: | 29521.1171568804@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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"
CREATE TABLE
regression=# create table bb (b1 real[] references aa);
CREATE TABLE
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-02-15 19:56:16 | Re: "anyelement2" pseudotype |
Previous Message | Tom Lane | 2007-02-15 19:34:40 | Re: "anyelement2" pseudotype |