Re: Package support for Postgres

Поиск
Список
Период
Сортировка
От Bill Studenmund
Тема Re: Package support for Postgres
Дата
Msg-id Pine.NEB.4.33.0110141022130.20774-100000@vespasia.home-net.internetconnect.net
обсуждение исходный текст
Ответ на Re: Package support for Postgres  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On Sun, 14 Oct 2001, Peter Eisentraut wrote:

> I have been pondering a little about something I called "package",
> completely independent of anything previously implemented.  What I would
> like to get out of a package is the same thing I get out of package
> systems on operating systems, namely that I can remove all the things that
> belong to the package with one command.  Typical packages on PostgreSQL
> could be the PgAccess admin tables or the ODBC catalog extensions.
>
> One might think that this could also be done with schemas.  I'm thinking
> using schemas for this would be analogous to installing one package per
> directory.  Now since we don't have to deal with command search paths or
> file system mount points there might be nothing wrong with that.
>
> Packages typically also have post-install/uninstall code, as does this
> proposed implementation, so that would have to be fit in somewhere.
>
> This is basically where my thinking has stopped... ;-)
>
> Now I'm also confused as to what this package system really represents:
> Is it a namespace mechanisms -- but Oracle does have schemas; or is it a
> package manager like I had in mind -- for that it does too many things
> that don't belong there; or is it a mechanism to set up global variables
> -- that already exists and doesn't need "packages".

It is an implimentation of Oracle Packages for PostgreSQL, taking
advantage of some of PostgreSQL's abilities (the aggregates & operators in
a package bit is new). It is a tool to help developers create large
projects and/or reuse code.

It is not schema support; schema support operates on a level above package
support. It is also not the package support you had in mind. That support
is different. What you describe above is packaging which primarily helps
the admin, while this packaging primarily helps the procedure developer.
That difference in emphasis is why this package support does things an
administrator-focused package system wouldn't.

Also, please note that while many of PostgreSQL's procedure languages
might not need global variable support, PL/pgSQL does.

Take care,

Bill



В списке pgsql-hackers по дате отправления:

Предыдущее
От: mlw
Дата:
Сообщение: Re: Pre-forking backend - new idea
Следующее
От: Tom Lane
Дата:
Сообщение: Re: http link to ftp download area broken