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

Reply via email to