public inbox for [email protected]
help / color / mirror / Atom feedFrom: Swaha Miller <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: support for CREATE MODULE
Date: Fri, 4 Feb 2022 12:52:08 -0800
Message-ID: <CAPXknY7v2AX+Pvbw9+_4AWSRC6J49dGTBre61aZfJcU0dCemuA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAFj8pRCBKqh=hs-QM9dscC5GfeGbKam=2zGH8ybzkYAAVgjFKg@mail.gmail.com>
<[email protected]>
On Thu, Feb 3, 2022 at 5:42 PM Alvaro Herrera <[email protected]>
wrote:
> On 2022-Feb-03, Pavel Stehule wrote:
>
> > The biggest problem is coexistence of Postgres's SEARCH_PATH object
> > identification, and local and public scopes used in MODULEs or in
> Oracle's
> > packages.
> >
> > I can imagine MODULES as third level of database unit object grouping
> with
> > following functionality
> >
> > 1. It should support all database objects like schemas
>
> I proposed a way for modules to coexist with schemas that got no reply,
> https://postgr.es/m/[email protected]
>
Yes, I arrived a little after that thread, and used that as my starting
point.
The POC patch Jim Mlodgenski had on that thread was similar to your
proposed
way - modules were rows in pg_namespace, with the addition of a new column
in pg_namespace for the nspkind (module or schema.)
Jim had asked about two options -- the above approach and an alternative
one
of having a pg_module system catalog and got some input
https://www.postgresql.org/message-id/2897116.1622642280%40sss.pgh.pa.us
Picking up from there, I am exploring the alternative approach. And what
qualified
names would look like and how they get interpreted unambiguously, when
schemas and modules co-exist. (Also, being new to PostgreSQL, it has been a
great learning exercise for me on some of the internals of PostgreSQL.)
With modules being their own type of object stored in a pg_module system
catalog, deconstructing a qualified path could always give precedence to
schema over module. So when there is function f() in schema s and another
function f() in module s in schema public, then s.f() would invoke the
former.
What are some other directions we might want to take this patch?
I still think that that idea is valuable; it would let us create
> "private" routines, for example, which are good for encapsulation.
> But the way it interacts with schemas means we don't end up with a total
> mess in the namespace resolution rules. I argued that modules would
> only have functions, and maybe a few other useful object types, but not
> *all* object types, because we don't need all object types to become
> private. For example, I don't think I would like to have data types or
> casts to be private, so they can only be in a schema and they cannot be
> in a module.
>
> Of course, that idea of modules would also ease porting large DB-based
> applications from other database systems.
>
Indeed. Looking at commercial databases Oracle and Microsoft SQLServer,
they both have implemented module-like structures.
Swaha Miller
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: support for CREATE MODULE
In-Reply-To: <CAPXknY7v2AX+Pvbw9+_4AWSRC6J49dGTBre61aZfJcU0dCemuA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox