Re: Packages: Again

From: Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Packages: Again
Date: 2017-01-12 23:35:21
Message-ID: CAMsr+YGyV84yojGBBYuqT2Xouo5wDtGVcEzKmbDr6AVgtaO=jg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13 Jan. 2017 00:54, "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:

On 01/11/2017 04:12 PM, Craig Ringer wrote:

What aspects / features of packages were the key issues?
>

Unfortunately we didn't get too far into it because the webinar was about
Postgres specifically. That said, I have been doing some followup. Here is
some of it:

because packages[1]

o break the dependency chain (no cascading invalidations when you install a
new package body -- if you have procedures that call procedures --
compiling one will invalidate your database)

o support encapsulation -- I will be allowed to write MODULAR, easy to
understand code -- rather then MONOLITHIC, non-understandable procedures

o increase my namespace measurably. package names have to be unique in a
schema, but I can have many procedures across packages with the same name
without colliding

o support overloading

o support session variables when you need them

o promote overall good coding techniques, stuff that lets you write code
that is modular, understandable, logically grouped together....

So far that's all "that'd be nice, but isn't a technical barrier" stuff.

Package variables for example. When _do_ you _need_ them? For what? (I'm
aware of some uses but "when you need them" helps us not at all).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-01-13 00:00:07 pgsql: Fix field order in struct catcache.
Previous Message Merlin Moncure 2017-01-12 21:59:05 Re: Retiring from the Core Team