Re: get_cast_func syscache utility function

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: get_cast_func syscache utility function
Date: 2014-11-05 16:48:43
Message-ID: 545A54EB.3020506@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 11/05/2014 10:10 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2014-11-05 17:00:32 Re: Time to remove dummy autocommit GUC?
Previous Message Jim Nasby 2014-11-05 16:46:07 Re: Repeatable read and serializable transactions see data committed after tx start