Andy Fan <zhihuifan1213@163.com> writes:
> You understood me correctly and I thought we should maintain one version
> two years ago, so I tried to implement this idea today. The first issue I
> want to talk about now how to define the function protocol in SQL, take
> int4out for example:
> master: cstring int4out(integer);
> New protocol: void int4out(integer, internal). and the internal is
> StringInfo acutally.
> The direct impaction would be:
> master support:
> postgres=# select int4out(8);
> int4out
> ---------
> 8
> (1 row)
> After our change, user could not invoke any {type}out function anymore
> in SQL since it takes 'internal' as an agrument. I am not sure if people
> would write SQL like this, but it'd be good to have a talk about this.
I think you missed the point of what I said two years ago: you will
never be able to remove the existing output function API, nor the
per-datatype functions that implement that API. Even if we were
willing to convert every last one of the in-core callers and callees,
doing that would break too much non-core code. So the above example
is never going to stop working.
We can consider implementing a new datatype output API alongside the
existing one. But it'd likely not be callable from SQL, so the
question of SQL compatibility is moot.
My own guess is that even if we built a new API, only a fairly small
number of datatypes would find it worth the trouble to support.
The potential win seems clear for, say, textout: there's really no
computation to do, only data copying, so halving the amount of
copying is attractive. But I bet you won't measure much percentage
improvement for numeric_out or point_out.
This line of thought suggests that maybe some special-purpose hack
would be a better answer than defining a new datatype API. It's hard
to tell without some concrete performance numbers, which are sadly
lacking in this thread.
regards, tom lane
