On 01/11/2011 02:32 AM, J. Hondius wrote:
> What are my options to stop the legacy app from failing?
IMO there aren't any good ones except "fix the legacy app not to be
brain-dead about character encodings".
> -Is there a setting to tell PostgreSQL to fail the character gracefully
> by substuting it?
The problem there is that a round-trip via the client is no longer a
safe no-change operation.
UPDATE tablename SET x = x WHERE ....;
no longer means the same as:
SELECT x FROM tablename WHERE ....;
-- client reads value of 'x'
UPDATE tablename SET x = 'value-from-client';
This is particularly critical in cases where the client may issue an
UPDATE that lists values for all fields, changed and not, when making a
change to a field. This is common in ORM systems, which usually list all
fields mapped by the object without caring which ones might actually be
different from the DB.
If you can verify that the legacy app never UPDATEs fields that might
contain textual data containing unicode chars inserted/updated via the
Java app, you could probably get away with this approach. Alas, I don't
think you can do it via Pg settings, you'd have to modify your legacy
app's SQL to remap the chars, which you probably can't do. Maybe you
could modify the Pg ODBC driver to do the remapping you desire -
assuming your legacy app talks to the database via ODBC.
> -Should i filter out all non win1252 charachters at the new java app and
... thus prolonging your pain. Once the legacy app is gone, you'll be
stuck with the limitations of the Java app, which by then you probably
won't able to or allowed to change to permit unicode for one reason or
another.
If you *do* decide to filter out unsupported chars, make sure it's
configurable in the app without source code changes and that both modes
get covered by your unit tests. Be sure it's ALWAYS ready to switch to
unicode as soon as the legacy stuff is gone.
This is probably what I'd do in your situation, if I couldn't fix or
retire the legacy app. I'd just make really, really sure I could always
enable full char encoding support later.
> substitute them? (not so nice, i'd like to have the chars in the db)
Ick.
--
Craig Ringer