Excerpts from Dimitri Fontaine's message of vie oct 22 10:43:58 -0300 2010: > Itagaki Takahiro <itagaki.takah...@gmail.com> writes:
> > * There are some inconsistency between extension names in \dx+ view > > and actual name used by CREATE EXTENSION. > > - auto_username => insert_username > > - intarray => _int > > - xml2 => pgxml > > We might need to rename them, or add 'installer'/'uninstaller' entries > > into control files to support different extension names from .so name. > > Fixed by having the CREATE EXTENSION command consider it's being given > the name of the extension as found in the control file, rather than the > control file base name. Hang on. Did I miss something? Why doesn't the control file name equal the extension name? I think the idea that you have to scan the whole share directory and parse all control files to find the one you need is a bit strange. It seems more sensible to allow the variation to occur in the Makefile, i.e. _int/Makefile should contain EXTENSION=intarray Was this discussed previously? If so, why was this idea rejected? > > * pg_execute_from_file() and encoding > > It expects the file is in server encoding, but it is not always true > > because we support multiple encodings in the same installation. > > How about adding encoding parameter to the function? > > => pg_execute_from_file( file, encoding ) This seems sensible ... at least as sensible as it is to allow COPY to specify the encoding. > > CREATE EXTENSION could have optional ENCODING option. > > => CREATE EXTENSION name [ ENCODING 'which' ] This seems like putting the burden on the user on getting the command right. That seems prone to failure. > So after adding support for this option in the command, I realized it > might be useless. What I've done is implemented an 'encoding' parameter > in the control file, so that the extension's author / maintainer are > able to set that from there. That makes more sense. > As I began by implementing the syntax, I didn't remove it yet, and maybe > there's a use case for it. Some strange encoding setting might require > the DBA to override what the author thinks the script encoding is? I doubt this is necessary. If the DBA needs to override it (why?), it's possible to edit the file. > I didn't (yet) specified any encoding for the contrib control files, as > I'm not sure lots of thoughts have been given to them. Should I set > SQL_ASCII, following what file(1) tells me, or do we aim for another > encoding here, or is it useless (as I think) to set SQL_ASCII when the > default is the database encoding? 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. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
