Skip site navigation (1) Skip section navigation (2)

Re: contrib function naming, and upgrade issues

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib function naming, and upgrade issues
Date: 2009-03-22 20:27:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Heard about ? :)

Le 22 mars 09 à 14:29, Dave Page a écrit :
>>  - want to be able to do  INSTALL PACKAGE foo;  without needing to
>>   mess with .sql files.  This might default to looking for
>>   $libdir/, or there might be a mechanism to register packages
>>   globally or locally.

Part of the proposal.

>>  - want to be able to do  INSTALL PACKAGE foo VERSION 1;  and get
>>   the version 1 API rather than whatever the latest is.

To be added to the proposal.

>>  - want to be able to do  INSTALL PACKAGE foo SCHEMA bar;  rather
>>   than having to edit some .sql file.

Part of the proposal (install time variables/options/parameters).

>>  - want to be able to do  DROP PACKAGE foo;

Part of the proposal.

>>  - want pg_dump to not output the definitions of any objects that
>>   belong to a package, but instead to output an INSTALL PACKAGE foo

Part of the proposal.

> I think using PACKAGE is a bad idea as it'll confuse people used to
> Oracle. MODULE perhaps?

Using package would tie us into supporting oracle syntax, which nobody  
actually wants, it seems. Or at least we have to reserve the keyword  
for meaning "oracle compliant facility".

Module on the other hand is already used in PostgreSQL to refer to the  
dynamic lib you get when installing C coded extensions (.so or .dll),  
what we miss here is a way to refer to them in pure SQL, have their  
existence cared about in the catalogs. That's the part Tom Dunstan  
worked on IIRC.
He also worked out some OS level tools for module handling, but I  
think I'd prefer to have another notion in between, the extension.

The extension would be a new SQL object referring to zero, one or more  
modules and one or more SQL scripts creating new SQL objects (schemas,  
tables, views, tablespaces, functions, types, casts, operator classes  
and families, etc, whatever SQL scripting we support now --- yes,  
index am would be great too). Those would depend (pg_depend) on the  
package SQL object. I don't think we need to be able to nest a package  
creation inside the package SQL scripts, but hey, why not.

So my vote is for us to talk about modules (.so) and extensions (the  
packaging and distribution of them). And this term isn't even new in  
PostgreSQL glossary ;)


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-03-22 20:27:42
Subject: Re: typedefs for indent
Previous:From: Dimitri FontaineDate: 2009-03-22 20:16:59
Subject: Re: contrib function naming, and upgrade issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group