Re: contrib function naming, and upgrade issues - Mailing list pgsql-hackers

On Sun, Mar 22, 2009 at 7:54 AM, Andrew Gierth
<andrew@tao11.riddles.org.uk> wrote:
>>>>>> "Robert" == Robert Haas <robertmhaas@gmail.com> writes:
>
>  >> I'm hesitant to do that when we don't yet have either a design or
>  >> a migration plan for the module facility.  We might find we'd shot
>  >> ourselves in the foot, or at least complicated the migration
>  >> situation unduly.
>
>  Robert> I think there have been a few designs proposed, but I think
>  Robert> part of the problem is a lack of agreement on the
>  Robert> requirements.  "module facility" seems to mean a lot of
>  Robert> different things to different people.
>
> Some ideas:
>
>  - want to be able to do  INSTALL PACKAGE foo;  without needing to
>   mess with .sql files.  This might default to looking for
>   $libdir/foo.so, or there might be a mechanism to register packages
>   globally or locally.
>
>  - want to be able to do  INSTALL PACKAGE foo VERSION 1;  and get
>   the version 1 API rather than whatever the latest is.
>
>  - want to be able to do  INSTALL PACKAGE foo SCHEMA bar;  rather
>   than having to edit some .sql file.
>
>  - want to be able to do  DROP PACKAGE foo;
>
>  - want pg_dump to not output the definitions of any objects that
>   belong to a package, but instead to output an INSTALL PACKAGE foo
>   VERSION n SCHEMA x;

This seems about right to me.  I think the key to getting this done is
to keep the design as simple as possible and to avoid entanglements
with other features that may need to be designed independently and
first. I think there's a good argument to be made that package
management could benefit from the notion of a variable.  For example,
you might want to write a SQL script or PL/pgsql procedure where
?{version}, or some equally inscrutable glyph, refers to the version
specified in the INSTALL MODULE command.

I'm deeply skeptical about this approach.  Either variables are useful
in PL/pgsql - as I tend to believe - or they aren't - as I'm sure can
be argued.  If they're useful, though, they are probably useful in
many contexts other than package management.  So I would suggest that
either a concerted effort needs to be made to design and implement a
useful variable facility (and then we can use it for package
mangement, too) or package management needs to be made to work without
variables (and then if we eventually add them in general we can use
them fpr package management, too).  On that basis, I'm inclined to
suggest that the SCHEMA and VERSION clauses you've proposed here
should be dropped for the first version of this, because I think it
will be very, very difficult to implement them without variables.

We also, I think, need to try very hard to avoid getting sucked into
creating a CPAN-like system for installing modules *on the machine*.
We need to focus on how the modules get sucked into PostgreSQL once
the OS-level packaging system (RPM, deb, whatever), or the system
administrator, have gotten the files installed in some suitable place
on the local host, and we now want to make PostgreSQL know about and
use them.  It might be nice to have a system that does the whole
thing, soup to nuts, but again, that's something that can be added
later and used by only those that want it.

So taking into account suggestions elsewhere on this thread, I suggest
"INSTALL MODULE foo" and "DROP MODULE foo".  It's pretty clear what
DROP MODULE foo should do, but the semantics of INSTALL MODULE foo are
a bit less clear.  I suspect that it's going to boil down to running a
SQL script, which will need to somehow get that module installed.  To
make that work, I think we need "CREATE MODULE foo" and then "CREATE
<TABLE|VIEW|FUNCTION|...> ... MODULE foo".  So the SQL script will
create the module and then create all of the objects and make them
depend on the module using the optional "MODULE foo" clause.

...Robert