Re: set_client_encoding is broken

Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)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