Re: Charset/collate support and function parameters - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Charset/collate support and function parameters
Date
Msg-id 20041031.173219.55719036.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: Charset/collate support and function parameters  (Dennis Bjorklund <db@zigo.dhs.org>)
Responses Re: Charset/collate support and function parameters
List pgsql-hackers
> > 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


pgsql-hackers by date:

Previous
From: Ian Barwick
Date:
Subject: Re: 8.0b4: COMMIT outside of a transaction echoes ROLLBACK
Next
From: Dennis Bjorklund
Date:
Subject: Re: Charset/collate support and function parameters