>>> - 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
