Re: Extensions, this time with a patch

Excerpts from Dimitri Fontaine's message of vie oct 22 10:43:58 -0300 2010:
> Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)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 <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support