Tom Dunstan <[EMAIL PROTECTED]> 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

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


Reply via email to