Re: How to add locale support for each column?
От | Greg Stark |
---|---|
Тема | Re: How to add locale support for each column? |
Дата | |
Msg-id | 87656akv1t.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: How to add locale support for each column? (Dennis Bjorklund <db@zigo.dhs.org>) |
Ответы |
Re: How to add locale support for each column?
Re: How to add locale support for each column? |
Список | pgsql-hackers |
Dennis Bjorklund <db@zigo.dhs.org> writes: > Still, we want the final solution to be what the sql standard specify. A > function as the proposed is however useful until a standard sql solution > is implemented. I've used a similar function for some projects and it have > worked well for me also. I haven't read the standard in this area (and the sections I have read don't lead me to think reading this section would be a trivial task), but from what 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. That would mean the entire column can only store strings from a single locale. 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. And worse, for user-provided input where each input could be in the user's locale language I wouldn't be able to store it in a properly normalized table where one column stores the user's input in whatever locale he prefers. 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. (I discussed it on the list but strangely the list archives search isn't finding it) > I think such a function fits perfect in contrib. I would like to see all the locale handling functions people have proposed over time gathered up and merged into a single coherent source base. There are probably a lot of duplicate code, and some could probably benefit from copying code from others. I don't think this is just a stop-gap solution though. I expect it would live on in contrib and continue to be useful even if the standard locale handling is ever implemented -- which will only happen if someone somewhere finds it would actually be useful for their needs. Possibly it would be useful to consider this as a low level interface. Then define a localized data type that uses it to implement the standard behaviour. -- greg
В списке pgsql-hackers по дате отправления: