Re: support for CREATE MODULE
От | Alvaro Herrera |
---|---|
Тема | Re: support for CREATE MODULE |
Дата | |
Msg-id | 202202040142.luk526wfnjjl@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: support for CREATE MODULE (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: support for CREATE MODULE
Re: support for CREATE MODULE |
Список | pgsql-hackers |
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/202106021908.ddmebx7qfdld@alvherre.pgsql 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. What do others think? -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
В списке pgsql-hackers по дате отправления: