On 19 Sep 2004, Greg Stark wrote:
> I've seen people describe here I think the standard behaviour will be nigh
> useless anyway. From what I understand the standard has you declare a locale
> per column.
Yes, you can define a default collation for a column if you want to but
more important you can set the charset and encoding for a column.
> That would mean the entire column can only store strings from a
> single locale.
You store strings in a charset/encoding. The same charset can use
different collations when you compare strings later on.
> So in my application I would need to declare a new set of columns in every
> table every time I localize it for a new language.
Not at all, you can just tell it to use another collation in your query.
The collation for the column is just the default. In your query you can do
something like
SELECT ... ORDER BY foo COLLATE "sv_SE"
I'm not 100% sure of the syntax of the language identifier. but something
like that.
> I actually would prefer an interface like he describes. And I think it's
> enlightening that everyone that tries their hand at this seems to come
> up with an interface much like this. You say you did for example, and I
> did also when I needed a strxfrm interface.
This is just because functions is the way you extend postgresql as a user.
It's much easier then to add language constructs.
The standard is clear (as clear as an sql standard ever is :-) and most of
the other databases implements it. I dont think we should make up our own
system and have that as the implementation goal. Until we have the
standard solution, a simple function like the discussed is useful and
putting it in contrib is what I prefer. I would use it.
--
/Dennis Björklund