Re: Extensions, this time with a patch - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Extensions, this time with a patch
Date
Msg-id m2y69q3ufp.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Extensions, this time with a patch  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Extensions, this time with a patch  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: Extensions, this time with a patch  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Extensions, this time with a patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.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


pgsql-hackers by date:

Previous
From: Brendan Jurd
Date:
Subject: Re: Integer input functions for date and timestamp
Next
From: Dimitri Fontaine
Date:
Subject: Re: Extensions, this time with a patch