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