Zdenek Kotala <zdenek.kot...@sun.com> writes: > [4a9ae815.696e:1] LOG: connection received: host=[local] > [4a9ae815.696e:2] LOG: connection authorized: user=postgres database=postgres > [4a9ae815.696e:3] LOG: conversion between UTF8 and LATIN2 is not supported > [4a9ae815.696e:4] FATAL: invalid value for parameter "client_encoding": > "UTF8"
> The assign_client_encoding->SetClientEncoding fails to find conversion > function. Hmm. The reason this used to work is that SetClientEncoding does no real work if it's invoked before InitializeClientEncoding. The old method of handling client_encoding in the client's startup message had the setting get processed before InitPostgres, then in InitPostgres we'd call InitializeClientEncoding within the startup transaction, and it would complete the unfinished catalog lookup. In CVS HEAD we postpone the GUC processing till after InitPostgres, but it's still outside of any transaction, so SetClientEncoding just fails. There are a number of possible solutions: 1. We could revert the changes in GUC handling, ie go back to applying non-SUSET GUCs before InitPostgres and SUSET ones afterwards. I don't much care for this; that code was really ugly, and I'm still worried about the possible security exposure of letting not-yet-authenticated users set GUCs, even ones we think are harmless. 2. Move the InitializeClientEncoding call out of InitPostgres and put it in PostgresMain after the GUC variables are all set. This is pretty bad from a performance point of view, though, since it appears to require a second startup-time transaction. 3. Push the startup-packet GUC processing (approx. lines 3340..3395 of postgres.c, as of CVS HEAD) into InitPostgres, so it can be run during the startup transaction. This is not too unclean, though it would mean exporting process_postgres_switches() from postgres.c; I guess the main thing I don't like about it is that InitPostgres has enough weird responsibilities already. I'm leaning to the third choice, but I wonder if anyone has any comments or better ideas. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers