Thread: Re: [HACKERS] Package support for Postgres

Re: [HACKERS] Package support for Postgres

From
Jean-Michel POURE
Date:
>What do folks think?
>Take care,
>Bill

Hello Bill,

The community have been waiting for packages for a long time. I don't
believe you did it!!!

IMHO most applications do not fully benefit from the power of PostgreSQL
because transactions are performed at application lever
(PHP/asp/Java/Application server). Sometimes, libraries are mapped to
database structure, which is nonsense when a simple view with left joins
can solve a problem.

Most applications should be developed/ported at PostgreSQL level using the
full range of available tools (transactions, triggers, views, foreign keys,
rules and off course PL/pgSQL). This is much easier and powerful. Then, all
you need is to display information using a good object-oriented language
(Java/PHP).

With the help of packages, a lot of developers will probably release GPL
libraries and PostgreSQL will become the #1 database in the world.

At pgAdmin team, we were thinking of developing packages at client level.
This is nonsense when reading your paper. The ability of defining context
levels is a great feature. Question: how do you map package to PostgreSQL
objects (tables, views, triggers)? Is there any possibility of defining
templates? Can this be added to packages in the future with little impact
on PostgreSQL internals?

Now, we can only thank you for bringing Packages to PostgreSQL.

Best regards,
Jean-Michel POURE
pgAdmin Team

Re: [HACKERS] Package support for Postgres

From
Bill Studenmund
Date:
On Sat, 13 Oct 2001, Jean-Michel POURE wrote:

> >What do folks think?
> >Take care,
> >Bill
>
> Hello Bill,
>
> The community have been waiting for packages for a long time. I don't
> believe you did it!!!
>
> IMHO most applications do not fully benefit from the power of PostgreSQL
> because transactions are performed at application lever
> (PHP/asp/Java/Application server). Sometimes, libraries are mapped to
> database structure, which is nonsense when a simple view with left joins
> can solve a problem.
>
> Most applications should be developed/ported at PostgreSQL level using the
> full range of available tools (transactions, triggers, views, foreign keys,
> rules and off course PL/pgSQL). This is much easier and powerful. Then, all
> you need is to display information using a good object-oriented language
> (Java/PHP).
>
> With the help of packages, a lot of developers will probably release GPL
> libraries and PostgreSQL will become the #1 database in the world.

Yep. PostgreSQL is within reach of really challenging the commercial
databases. I think the core developers are working on the changes needed
to challenge the commercial db's in terms of speed and performance for big
datastores (WAL, working to prevent OID rollover, etc.). Packages address
a different side of what will be needed to challenge the big boys - better
stored procedure support. :-)

> At pgAdmin team, we were thinking of developing packages at client level.
> This is nonsense when reading your paper. The ability of defining context
> levels is a great feature. Question: how do you map package to PostgreSQL
> objects (tables, views, triggers)? Is there any possibility of defining
> templates? Can this be added to packages in the future with little impact
> on PostgreSQL internals?

Packages don't really map to DB objects (tables, views, triggers) at the
moment. Have you used Oracle much? These packages are a direct translation
of Oracle packages, with a few PostgreSQL extentions thrown in (Oracle
doesn't have PostgreSQL's ability to add aggregates, operators, and system
types AFAIK, so their packages likewise don't, and types in packages AFAIK
are package-specific).

I forget who said it, but operators (and aggregates) are basically just
sugar wrapped around functions; these packages are another form of sugar
wrapped around functions. To start adding views and tables and triggers
makes packages more than just special sugar around functions.

Also, my big concern is that if we start adding tables and views and
triggers to packages, pg_dump becomes a nightmare.

> Now, we can only thank you for bringing Packages to PostgreSQL.

You're welcome.

Take care,

Bill