Re: "anyelement2" pseudotype
От | Tom Lane |
---|---|
Тема | Re: "anyelement2" pseudotype |
Дата | |
Msg-id | 3412.1171653613@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: "anyelement2" pseudotype (Tom Dunstan <pgsql@tomd.cc>) |
Ответы |
Re: "anyelement2" pseudotype
|
Список | pgsql-hackers |
Tom Dunstan <pgsql@tomd.cc> writes: > Tom Lane wrote: >> 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? > To begin with I'll need to do a survey of the call sites > to see what they really need, since perhaps it isn't what the coerce > functions are currently offering. :) I realized that I can probably fix ATAddForeignKeyConstraint to do the right thing by having it pass the two actual column types to can_coerce_type, thus allowing check_generic_type_consistency to kick in and detect the problem. I haven't got round to trying that (up to my rear in planner bugs ATM :-() but I think the immediate problem can be dealt with without refactoring. Still, if you have any ideas for making this code cleaner, I'm all ears. regards, tom lane
В списке pgsql-hackers по дате отправления: