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).
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 |