Thread: domains code query

*
domains.c contains the followng snippet in domain_in():

   else* *if* (my_extra->domain_type != domainType)    domain_state_setup(my_extra, domainType, false,
    fcinfo->flinfo->fn_mcxt);
 


We were just looking at this code (in the context of implementing enums) and wondered when this case might arise. 
Would it be when more than one domain is used in a table row? Or are we smarter than that?

Putting it another way, how often are fcinfo/flinfo created and reused?

TIA

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> domains.c contains the followng snippet in domain_in():

>     else* *if* (my_extra->domain_type != domainType)
>         domain_state_setup(my_extra, domainType, false,
>                            fcinfo->flinfo->fn_mcxt);

> We were just looking at this code (in the context of implementing enums) and wondered when this case might arise. 
> Would it be when more than one domain is used in a table row? Or are we smarter than that?

I think it's just defensive programming.  The logic was copied from
array_in which does something similar, but AFAIR there's not really
any code path which would feed differing input types to the same
function call within a single query execution.  Still, since it takes
only an extra comparison or so to handle the scenario, why not?
        regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> domains.c contains the followng snippet in domain_in():
>
>>     else* if (my_extra->domain_type != domainType)
>>         domain_state_setup(my_extra, domainType, false,
>>                            fcinfo->flinfo->fn_mcxt);
>
>> We were just looking at this code (in the context of implementing enums)
>> and wondered when this case might arise.
>> Would it be when more than one domain is used in a table row? Or are we
>> smarter than that?
>
> I think it's just defensive programming.  The logic was copied from
> array_in which does something similar, but AFAIR there's not really
> any code path which would feed differing input types to the same
> function call within a single query execution.  Still, since it takes
> only an extra comparison or so to handle the scenario, why not?
>


Sure. We were hoping it was something like that.

cheers

andrew