Re: Extensions, this time with a patch

Excerpts from Dimitri Fontaine's message of vie oct 22 16:21:14 -0300 2010:

> So I think it's a good compromise, and as it's superuser-only I would
> think it's acceptable as-is. Apparently it's not, which ain't the end of
> the world but an unexpected surprise for me. And when I don't
> understand, I tend to insist until I do or until I resign, whichever
> comes first, but you would know that by now :)

Yeah, well, this is just my personal opinion. Others are welcome to
chime in.

> I'll go rework the patch sometime later to drop the name from the
> control file, but that also means fixing several contrib modules by
> changing their file names, operation for which the project has no policy
> yet as far as I understand (we used CVS before).

Change what file names? You lost me there. I thought the extension
name was going to be equal to the control file name, and said control
file doesn't exist yet, so you don't need to rename any existant file.
Am I confusing something?

That said, I don't think there's any reason now to stop a committer from
renaming files (as long as this has been previously discussed and agreed
to, just like any other commit).

> Superuser only. To manage extensions, nothing to do with live load or
> user queries. But if you say performance is important here and 3ms to
> display all available extensions sucks, so be it.

To be honest I'm not all that concerned with raw performance here. I
just think that scanning a directory is a strange way for the search to
behave.

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