Re: "anyelement2" pseudotype

Поиск
Список
Период
Сортировка
От Tom Dunstan
Тема Re: "anyelement2" pseudotype
Дата
Msg-id 45D63F44.5060409@tomd.cc
обсуждение исходный текст
Ответ на Re: "anyelement2" pseudotype  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: "anyelement2" pseudotype  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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?

Yeah, I remember thinking at the time that some of it was a bit 
backwards, but it's been almost 6 months since I did the original enum 
patch, so I'll need to refresh my memory. I'll have a look over the 
weekend and see if I can come up with something that'll work for these 
various cases. 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 completely agree that anything 
requiring call sites to understand specifics about ANY* types is a bad 
idea, the most that we would want would be a generic IsGeneric(typoid) 
macro, but it would be nice to hide that inside a coerce function as 
well. We'll see.

Cheers

Tom


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: HOT for PostgreSQL 8.3
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: buildfarm failure in XML code