Tom, Greg,
Please accept my considerable apologies. The fault was my own program that
loaded metadata into the text column, metadatafulltext. My reason (not a
sufficient excuse!) for overlooking the problem is that the Unicode is
invisible in psql windows, therefore it was not a simple matter of displaying
each row of metadatafulltext to examine its contents. Some rows got loaded
with Latin metadata, others with Greek, whereas each and every row needed both.
You both have been very helpful. In the future I will be careful as I can to
ensure any problems don't exist with my down read-write-create-selete software!
Thanks again for your help,
Ben
In message <26870.1193091184@sss.pgh.pa.us> Tom Lane <tgl@sss.pgh.pa.us>
writes:
> Benjamin Weaver <benjamin.weaver@classics.ox.ac.uk> writes:
> > I AM in fact running the db on Linux. Redhat 9. Are the encoding
parameters
> > wrong for Linux?
>
> Hmm ... RH 9 is awfully old. It's at least conceivable that you're
> getting bit by some glibc bug. However, if these are just plain LIKE
> calls and not ILIKE then I don't think that theory is very viable
> --- AFAICS the regular LIKE code doesn't depend on anything from the
> platform.
>
> A slightly more viable theory is that you're getting bit by a gcc bug.
> Did you build the Postgres executables in-house, and if not where did
> you get them from? It might be helpful if you'd show us the output
> of "pg_config".
>
> Again, if you could put together a self-contained test case (preferably
> a short psql script) it would be helpful so we could try the case on
> other machines. It's not at all clear at this point whether the bug
> is Postgres' fault or something about the underlying platform.
>
> regards, tom lane
--
Benjamin Weaver
Faculty Research Associate, Imaging Papyri Projects, Herculaneum Society,
Oxford
email: benjamin.weaver@classics.ox.ac.uk
phone: (0)1865 610236
