From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Swaha Miller <swaha(dot)miller(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: support for CREATE MODULE |
Date: | 2022-02-10 21:16:56 |
Message-ID: | 202202102116.zrver3tyuoov@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-Feb-04, Tom Lane wrote:
> If we invent modules I think they need to work more like extensions
> naming-wise, ie they group objects but have no effect for naming.
I think modules are an orthogonal concept to extensions, and trying to
mix both is messy.
The way I see modules working is as a "logical" grouping of objects --
they provide encapsulated units of functionality. A module has private
functions, which cannot be called except from other functions in the
same module. You can abstract them out of the database design, leaving
you with only the exposed functions, the public API.
An extension is a way to distribute or package objects. An extension
can contain a module, and of course you should be able to use an
extension to distribute a module, or even several modules. In fact, I
think it should be possible to have several extensions contribute
different objects to the same module.
But things like name resolution rules (search path) are not affected by
how the objects are distributed, whereas the search path is critical in
how you think about the objects in a module.
If modules are just going to be extensions, I see no point.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2022-02-10 21:47:15 | Re: Synchronizing slots from primary to standby |
Previous Message | Bruce Momjian | 2022-02-10 21:06:08 | Re: support for CREATE MODULE |