| 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: | Whole Thread | Raw Message | 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).
| 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 |