Re: Extensions, this time with a patch

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Well, things like pgfoundry project names are also restricted AFAICT and
> I don't think anyone has a problem with that.

For things you publish, sure. But extensions will also handle in-house
developments of functions and other in-database API-like stuff, in fact
any SQL script you have that you don't want to maintain in the database
dumps is an extension.

So it's broader than just public Open Source projects.

Anyway, my point is that by default there's no directory scanning: the
lookup is first directed towards ${extension-name}.control, of
course. Only when this file does not exists or its name property is
different from the extension name do we get to scan the directory, and
we stop as soon as we find the .control file with the right name in it.

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 :)

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).

For information, when we talk about performance problem, please note
that on my workstation with a default setup (not that it's important
here) we're talking about 86,420 ms for a loop of 100
perform * from pg_extensions;

That displays 36 extensions and needs to parse their files twice and for
some of them need to scan the directory and parse other extension
control files before to get to the right one. Average less than 1ms to
do all that on my workstation, and typically less than 3ms if you
include psql side of things.

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.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support