Tom Lane <t...@sss.pgh.pa.us> writes:
> Why is it necessary to have such a parameter at all? AFAICS it just
> adds complexity for little if any gain. Most extension files will
> probably be pure ASCII anyway. Dictionary files are *far* more likely
> to contain non-ASCII characters. If we've gotten along fine with
> requiring dictionary files to be UTF8, I can't see any reason why we
> can't or shouldn't take the same approach to extension files.
Don't forget that extensions are not just contrib or third party Open
Source software, but a lot of in-house code, mostly functions written in
SQL and PLpgSQL. In non-English speaking countries, the parameter names
and comments are typically not written in English.
When we're talking Japan they have some quite specifics needs and I came
to understand that the database encoding and the script encoding are not
to be the same, usually. So I still vote for handling this parameter.
>> So, I think no additional complexity will be added even if we
>> support a configurable encoding as the third encoding.
>
> This is nonsense. The mere existence of the parameter requires code
> to support it and user documentation to explain it.
The whole documentation needs to be:
<varlistentry>
<term><replaceable class="parameter">encoding</replaceable></term>
<listitem>
<para>
The <literal>encoding</literal> in which the script file is read.
</para>
</listitem>
</varlistentry>
The code to support that is on the order of 25 lines of code, once we
get rid of the SQL command level support for it.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
