Peter Eisentraut <peter_e@gmx.net> writes:
> However, if the model is that it should appear to clients that the entire
> setup magically runs in "their" encoding then the other behaviour would be
> better. In that case the database encoding is really only an optimization
> hint because the actual encoding in the server is of no matter. This
> model would certainly be attractive as well, but there could be a few
> problems. For instance, I don't know if the convert() function would make
> sense then. (Does it even make sense now?)
I'm not sure that it does; it seems not to fit the model well at all.
For example, if I do "SELECT convert(somestring, someencoding)" where
someencoding is anything but the server's encoding, then I will get
bogus results, because when the data is returned to the client it
will get an inappropriate server-to-client-encoding translation
applied to it. Even if I ask to convert to the client encoding,
I will get wrong answers (two passes of the conversion). Whatever you
might expect convert to do, that wouldn't seem to be it.
> Also, we do need to consider carefully how to interface this "illusion" to
> operations contained strictly within the server (e.g., CREATE TABLE AS,
> column defaults) and to procedural languages that may or may not come with
> encoding ideas of their own.
True. I think that pltcl has now got this more or less licked, but
plperl hasn't ...
regards, tom lane