Chapman Flack <jcfl...@acm.org> writes:
> On 04/15/25 10:52, Tom Lane wrote:
>> The problem from a PL's standpoint is "given this input or output
>> of type FOO, should I transform it, and if so using what?". So
>> the starting point has to be a type not a transform.
> Perhaps the efficiency argument is really "say a function has
> a list of 100 arguments and only one is of type foo, how many cycles
> are wasted in get_transform_tosql and get_transform_fromsql applied
> to all those other types?"
That, and also "how many cycles are wasted in get_transform_tosql and
get_transform_fromsql when there isn't any TRANSFORM clause at all?"
> If pg_proc had protransforms instead, that would add a step zero: looking
> up the declared transforms to make an in-memory list of (typid, tosqloid,
> fromsqloid). After that, get_transform_{tosql,fromsql} would be applied
> and return quickly when the passed typid isn't in that list.
I don't doubt there are other ways that this could be built. But
you've not really made the case that another way is better (let alone
enough better to be worth breaking backward compatibility for).
I think the "normal" case is that there isn't any TRANSFORM clause.
As long as that case falls through quickly, it's hard to credit that
there's any meaningful performance difference between different
arrangements here.
My own beef with the whole setup is that you can't specify *which*
arguments or results you want transformed. I don't believe that
this should have been keyed off data types to begin with. But
that design was the SQL committee's choice so we're stuck ...
regards, tom lane
