Re: Extensions, this time with a patch

Excerpts from Dimitri Fontaine's message of vie oct 22 12:25:07 -0300 2010:

> Now, if we want to do it the other way round and force extension name to
> be the filename, we will have to live with all the restrictions that
> filename imposes and that are not the same depending on the OS and the
> filesystem, I think, and with systems where we have no way to know what
> is the filesystem encoding. Am I wring in thinking that this might be a
> problem?

I don't see a problem limiting extension names to use only ASCII chars,
and a subset of those, at that.  They're just names.  If you want to get
fancy you can use the description.

> If that's not a problem and we want to have the extension name into the
> control file name, then I'll go remove the name property there.
> 
> > 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?
> 
> It's already possible to do this. But the contrib uses _int.sql.in and
> MODULE_big = _int and I didn't change that. I had the control file named
> the same as the script file, but with the current implementation we can
> change that (there's a script property in the control file).

I think it makes more sense to change the script name in the control
file.  That way you never need to scan anything.  As for this being
seldom used, consider the case where the user mistypes the extension name.
You will be scanning the directory without good reason.


> >> > * 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.
> 
> Well why not, for convenience, but you can surround the call to this
> function with SET client_encoding and get the same behaviour. Will add
> the argument if required, though.

I don't think it is.  In fact, it seems better to leave it out.  CREATE
EXTENSION will have its own mechanism for specifying the encoding (which
it'll obtain from the control file), so I don't see the need.

> >> > 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.
> 
> Given that the control file now supports an encoding parameter, I don't
> see what this is good for, but I might be missing something obvious for
> people working with different encodings etc. Japan seems to be quite
> special as far as encodings are concerned.

Seems we're both arging the say way, but neither of us is Japanese ;-)

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support