Re: "anyelement2" pseudotype - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "anyelement2" pseudotype
Date
Msg-id 3412.1171653613@sss.pgh.pa.us
Whole thread Raw
In response to Re: "anyelement2" pseudotype  (Tom Dunstan <pgsql@tomd.cc>)
Responses Re: "anyelement2" pseudotype
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: buildfarm failure in XML code
Next
From: "Florian G. Pflug"
Date:
Subject: Confusing message on startup after a crash while recovering