"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> But OTOH, I feel we should just stop exporting them now; I don't think
> there's a legitimate use case for a client application to use them.
Actually, that doesn't seem workable as a solution to our immediate
problem: we surely can't remove exported symbols without doing a soname
bump.
Also, in general it seems like a bad idea to try to freeze the values of
the enum: what happens when we want to add some more server-side
encodings? We will never be able to do that without moving the
client-only ones.
I think what we must do here is decouple libpq's values of the enum from
the backend's. As long as a client talking to libpq does not have any
preconceived notions about what the numbers mean, it's fine. (And in
that mindset, we *do* need to export pg_encoding_to_char and so on,
so that clients can use those functions to map to encoding names instead
of making it up themselves.)
I'm becoming more and more convinced that this is initdb's bug not
libpq's. The problem stems from initdb using libpq's functions and
assuming that its numbers match up with pg_wchar.h. But note that
pg_wchar.h is not exported by libpq.
regards, tom lane
