>>> - Did we decide to ditch the encoding parameter for extension scripts
>>> and mandate UTF-8?
>>
>> No we didn't, we decided that the default encoding is UTF-8 and that any
>> contrib script defaults to UTF-8, so that it's not necessary to care
>> about the 'encoding' parameter in the control file there.
>>
>> Itagaki required that the extension code is encoding aware, and it
>> wasn't clear that the control file 'encoding' parameter would be enough
>> in his side of the world, so the encoding support is currently offered
>> to authors in the control file and users still can override it in the
>> CREATE EXTENSION command.
I think 'encoding' parameter is enough. Of course embedding encoding
specifiers in SQL files are better, but there would be technical problems.
(Just for reference: http://www.python.org/dev/peps/pep-0263/ )
>> I'm about sure that we don't want to remove that support, and I think
>> that the command part of it ain't required, but that's for people with
>> complex encoding problems to tell us IMO.
>
> Oh, I wasn't aware that Itagaki-san had objected to Tom's proposal.
I agree that "the default encoding is UTF-8", but it should be
configurable by the 'encoding' parameter in control files.
If we use UTF-8 as the the default encoding, we need to treat
3 encodings at once (server, client, and UTF-8) anyway.
So, I think no additional complexity will be added even if we
support a configurable encoding as the third encoding.
--
Itagaki Takahiro