On Sun, Oct 28, 2007 at 01:59:22AM +0200, Dennis Brakhane wrote: > I have some problems supporting "translatable columns" in a way that > is both efficient and comfortable for the programmer who has to write > SQL-Queries (we use iBatis) Maybe this helps a bit: http://salaam.homeunix.com/~ncq/gnumed/schema/gnumed-schema.html Look at the tables und functions under the i18n schema. Basically it provides a _() reimplementation in SQL, so select _(translatable_column) as translated_column from table_with_translatable_columns ... works as expected. Which language to translate to is set in another table which is evaluated by the _() function at runtime. You could evaluate that table from a view base on current_user() if you don't want to write 50+ views for the different languages. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match