From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Matt Miller <pgsql(at)mattmillersf(dot)fastmail(dot)fm>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: "anyelement2" pseudotype |
Date: | 2007-02-16 19:20:13 |
Message-ID: | 3412.1171653613@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Dunstan <pgsql(at)tomd(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2007-02-16 19:30:07 | Confusing message on startup after a crash while recovering |
Previous Message | Alvaro Herrera | 2007-02-16 19:07:45 | Re: pgsql: Better fix for determining minimum and maximum int64 values that |