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 по дате отправления: