Re: Charset/collate support and function parameters

Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> writes:
> On Sat, 30 Oct 2004, Tom Lane wrote:
>> I'm worried about the fact that instead of, say, one length(text)
>> function, we would now have to have a different one for every
>> characterset/collation.

> For some functions one really want different ones depending on the
> charset. For example the length function, then we will need to calculate
> the length differently for each charset. We can never have one length
> function that works for every possible charset.

Strange ... we seem to have one now ...

> We could have one pg function that do N different things inside
> depending on the charset, but that's not really a simplification.

Yes it is. It's about the same amount of actual code either way, and it
gets the job done without introducing huge headaches for the overloaded-
function resolution rules. That stuff is complicated and fragile enough
without introducing issues like whether to match optional subtype
information.

Basically, you're talking about a substantial increase in complexity in
the type resolution rules, and breaking a great number of internal APIs
(because they don't pass the information that would need to be passed),
in order to have a slightly different layout of the code that will
actually implement character-set-specific operations. I can't see that
that's a sensible use of development effort.

> The alternative is storing the charset and collation inside each string.
> That seems like a too big price to pay, it belong in the type.

No, the alternative you're proposing is too big a price to pay. It's
too much work for too little gain, and it's also too inflexible (I think
there will be cases where we don't want to nail down the character set
at datatype-resolution time).

regards, tom lane