Re: get_cast_func syscache utility function
От | Andrew Dunstan |
---|---|
Тема | Re: get_cast_func syscache utility function |
Дата | |
Msg-id | 545A54EB.3020506@dunslane.net обсуждение исходный текст |
Ответ на | Re: get_cast_func syscache utility function (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 11/05/2014 10:10 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> On 11/04/2014 01:45 PM, Tom Lane wrote: >>> In short, I'd rather see this addressed through functions with slightly >>> higher-level APIs that are capable of covering more cases. In most cases >>> it'd be best if callers were using find_coercion_pathway() rather than >>> taking shortcuts. >> Well, then, do we really need a wrapper at all? Should we just be doing >> something like this? >> if (typoid >= FirstNormalObjectId) >> { >> Oid castfunc; >> CoercionPathType ctype; >> ctype = find_coercion_pathway(JSONOID, typoid, >> COERCION_EXPLICIT, &castfunc); >> if (ctype == COERCION_PATH_FUNC && OidIsValid(castfunc)) >> { >> *tcategory = JSONTYPE_CAST; >> *outfuncoid = castfunc; >> } >> } > Well, of course, the question that immediately raises is why isn't this > code handling the other possible CoercionPathTypes ;-). But at least > it's pretty obvious from the code that you are ignoring such cases, > so yes I think this is better than what's there now. > > Also, it's equivalent to what's there now, I think. I wasn't intending to change the behaviour - if someone wants to do that they can submit a separate patch. cheers andrew
В списке pgsql-hackers по дате отправления: