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