Re: Extensions, patch v20 (bitrot fixes)

Tom Lane <tgl@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