I wrote:
> In the meantime I'm more convinced than ever that we should throw an
> error for attempting such a cast. If people are imagining that it will
> do something like that, we need to disillusion them.
BTW, I wrote up what I thought was a trivial patch to make this happen,
and promptly got a regression test failure:
CREATE TABLE enumtest_child (parent rainbow REFERENCES enumtest_parent);
INSERT INTO enumtest_parent VALUES ('red');
INSERT INTO enumtest_child VALUES ('red');
+ ERROR: casting to a polymorphic type such as anyenum is meaningless
+ LINE 1: ... FROM ONLY "public"."enumtest_parent" x WHERE "id"::pg_catal...
+ ^
+ QUERY: SELECT 1 FROM ONLY "public"."enumtest_parent" x WHERE
"id"::pg_catalog.anyenum OPERATOR(pg_catalog.=) $1::pg_catalog.anyenum FOR
SHARE OF x
INSERT INTO enumtest_child VALUES ('blue'); -- fail
What is happening is that the code to generate RI check queries is
blindly casting to the declared input type of the operator it's
selected, which here is "anyenum = anyenum". We could easily prevent
it from doing that for polymorphic input types; but since I tripped over
this case almost immediately, I'm wondering what other cases might be
out there that would get broken by throwing this error.
Seeing that this type of confusion hasn't come up before, I think it
might be better to leave things alone here.
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
