Re: Charset/collate support and function parameters

> > I wonder what is the intention to allow such that syntax. It seems
> > it's just useless since we could make a function bar() which accepts
> > any charsets.
>
> One could override the behaviour of functions by adding a charset and a
> adding new definition of an old function name for that charset. Like
> adding a new collation and define a new cmp() function for that
> collation that works different then some old definitons of cmp().

How could that be usefull? For example, length() returns character
length no matter what the charset/collation is. I hardly imagin a
function which changes its behavior according to charsets.

> The whole discussion came because I start to look at problems from what is
> in the specification and try to fit that into pg. Not everything will fit,
> it's just my starting point when discussing. Tom starts at the other end
> and then it looks like a big controversy.
>
> About the explosion of the number of functions needed. It's not obvious to
> me that there will be an explosion if one manage to allow both full types
> that include charset and more generic functions that work on any text
> type.

I don't understand your point. Today we already use one length()
function for any charsets as Tom has already pointed out.

> It seems to me that there are not that many interesting combinations
> anyway. Most applications will use one charset and define functions that
> work with just that charset.

Really? One of the objectives of i18n is an application can handle
multiple charsets. I don't want to write two applications just for the
charset difference, for example English and Japanese.

> Anyway, the only way to see what problems would arise is to try. I was
> hoping that the step A and B in the plan was something that we wanted no
> matter of how the locale problem was later solved. With those in place it
> would be easier to experiment.

The question in your approach is how you could handle the coercibility
property. It's a transient and on memory property thus will not fit
into the function declaration. No?
--
Tatsuo Ishii