Re: Extensions, patch v20 (bitrot fixes)

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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