SELECT * FROM "countries" WHERE "name"->'en' LIKE 'Ger%'

It does mean the function is being run on every column in the table, so there are performance considerations, but that's true of most of the schemas I've seen for translating this kind of data (One Big Table, tables where you previously had columns, etc, all lead to much more complex query plans).

I haven't looked into it in detail, but I think you could build an index on ("name"->'en') if you knew that you were going to query it in a way that would hit the index. Although if you were doing pattern matching, that might not help anyway...

Meanwhile, I must get round to updating the version online with the fixes that have been made to get it working in production here.

I haven't had a chance to try hstore yet - I've only recently got myself a decent dev environment where I could play around with installing that kind of thing. It's certainly something I should look into, as it's likely to have plenty of advantages over my cobbled together array system.

As for production use, I did persuade my colleagues to use it for some data like lists of resorts to use on a new Spanish website, and apart from a couple of inconsistencies with the way different Postgres versions handled the custom operators, which I need to look into, it seems to have worked out quite well. (I think the problem was with the wrong version of || being called, worked around by defining ||| instead...)

Rowan

Anyone tried it in production?

Werner