Re: Extensions, this time with a patch

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Yes. It's horrid for performance, and it's worse for understandability,
> and there's no obvious benefit to set against those. Please let's make
> the rule that the control file name equals the extension name.

Performance… well if you say that CREATE EXTENSION performance prevails
on its flexibility, let's say that I didn't expect it. See also my
previous mail for details (directory scanning only happens for those
extensions having chosen not to name their control file sensibly) and
the filesystem/OS problems (are they real?).

> But then you have to figure out what encoding it is, and you have to
> know that before you start reading the file. I think a better idea
> would be to do the same thing we did for text search config files:
> mandate that these files have to be in utf8.

Agreed, if as I understand it you're talking about the control file
itself, which supports an 'encoding' parameter that applies to the
SQL script.

>> I think it is OK to have the control files be pure ASCII (this doesn't
>> mean they are in SQL_ASCII though). The problems will start when we
>> decide to allow translations for extension descriptions. But we can
>> leave that for another day.
>
> Well, we can see the issue now, and anyway who's to say an extension
> might not want to load up some non-ASCII data?

The case is covered with the 'script' and 'encoding' parameters present
in v10 I think. If we force the control file itself to be UTF8 then we
can allow translations embedded in the file, it seems.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support