Re: support for CREATE MODULE

On Thu, Mar 17, 2022 at 04:30:43PM -0700, Nathan Bossart wrote: > On Thu, Mar 17, 2022 at 04:26:31PM -0700, Swaha Miller wrote: >> On Thu, Mar 17, 2022 at 4:16 PM Nathan Bossart >> wrote: >>> It seems unlikely that this will be committed for v15. Swaha, should the >>> commitfest entry be

Re: support for CREATE MODULE

On Thu, Mar 17, 2022 at 04:26:31PM -0700, Swaha Miller wrote: > On Thu, Mar 17, 2022 at 4:16 PM Nathan Bossart > wrote: > >> It seems unlikely that this will be committed for v15. Swaha, should the >> commitfest entry be adjusted to v16 and moved to the next commitfest? >> >> > Yes please,

Re: support for CREATE MODULE

On Thu, Mar 17, 2022 at 4:16 PM Nathan Bossart wrote: > It seems unlikely that this will be committed for v15. Swaha, should the > commitfest entry be adjusted to v16 and moved to the next commitfest? > > Yes please, thank you Nathan

Re: support for CREATE MODULE

It seems unlikely that this will be committed for v15. Swaha, should the commitfest entry be adjusted to v16 and moved to the next commitfest? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com

Re: support for CREATE MODULE

On Tue, Feb 15, 2022 at 12:29:54PM -0800, Swaha Miller wrote: > On Mon, Feb 14, 2022 at 4:58 PM Bruce Momjian wrote: > > I was working on a talk about microservices today and decided to create > > two schemas --- a public one that has USAGE permission for other > services > > with

Re: support for CREATE MODULE

st 16. 2. 2022 v 14:17 odesílatel Jim Mlodgenski napsal: > > > On Wed, Feb 16, 2022 at 12:20 AM Pavel Stehule > wrote: > >> >> The main issue in this case is fact, so plpgsql is fully integrated to >> Postgres (on second hand this integration is a big performance win). It is >> pretty different

Re: support for CREATE MODULE

On Wed, Feb 16, 2022 at 12:20 AM Pavel Stehule wrote: > > The main issue in this case is fact, so plpgsql is fully integrated to > Postgres (on second hand this integration is a big performance win). It is > pretty different from PL/SQL. In Oracle you have a package, or any other > similar

Re: support for CREATE MODULE

Hi > Yes, anything a user may want to do with modules is likely possible to > do already with schemas. But just because it is possible doesn't mean > it is not tedious and awkward because of the mechanisms available to do > them now. And I would advocate for more expressive constructs to enable

Re: support for CREATE MODULE

On Mon, Feb 14, 2022 at 4:58 PM Bruce Momjian wrote: > On Mon, Feb 14, 2022 at 07:42:21PM -0500, Bruce Momjian wrote: > > On Mon, Feb 14, 2022 at 03:23:07PM -0800, Swaha Miller wrote: > > > A prominent use case for grouping functions into modules would > > > be access control on the group as a

Re: support for CREATE MODULE

On Mon, Feb 14, 2022 at 07:42:21PM -0500, Bruce Momjian wrote: > On Mon, Feb 14, 2022 at 03:23:07PM -0800, Swaha Miller wrote: > > A prominent use case for grouping functions into modules would > > be access control on the group as a whole, with one command > > for an entire module instead of many

Re: support for CREATE MODULE

On Mon, Feb 14, 2022 at 03:23:07PM -0800, Swaha Miller wrote: > A prominent use case for grouping functions into modules would > be access control on the group as a whole, with one command > for an entire module instead of many individual functions. One reason > for such a grouping is to set ACLs.

Re: support for CREATE MODULE

On Thu, Feb 10, 2022 at 1:06 PM Bruce Momjian wrote: > On Thu, Feb 10, 2022 at 08:53:15AM -0800, Swaha Miller wrote: > > On Fri, Feb 4, 2022 at 3:51 PM Tom Lane wrote: > > > > Hm. If the functional requirement is "group objects without needing > > any out-in-the-filesystem

Re: support for CREATE MODULE

On Thu, Feb 10, 2022 at 4:17 PM Alvaro Herrera wrote: > 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

Re: support for CREATE MODULE

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

Re: support for CREATE MODULE

On Thu, Feb 10, 2022 at 08:53:15AM -0800, Swaha Miller wrote: > On Fri, Feb 4, 2022 at 3:51 PM Tom Lane wrote: > > Hm. If the functional requirement is "group objects without needing > any out-in-the-filesystem infrastructure", then I could see defining > a module as being exactly

Re: support for CREATE MODULE

On Fri, Feb 4, 2022 at 3:51 PM Tom Lane wrote: > Hm. If the functional requirement is "group objects without needing > any out-in-the-filesystem infrastructure", then I could see defining > a module as being exactly like an extension except there's no such > infrastructure --- and hence no

Re: support for CREATE MODULE

On 04.02.22 23:12, Tom Lane wrote: Right. We've looked into that before --- when I made pg_namespace, I called it that because I thought we might be able to support nested namespaces --- but it'd really create a mess. In particular, the SQL standard says what a three-part name means, and

Re: support for CREATE MODULE

Nathan Bossart writes: > On Fri, Feb 04, 2022 at 05:12:43PM -0500, Tom Lane wrote: >> On the whole I'm kind of allergic to inventing an entire new concept >> that has as much overlap with extensions as modules seem to. I'd >> rather try to understand what functional requirements we're missing >>

Re: support for CREATE MODULE

On Fri, Feb 04, 2022 at 05:12:43PM -0500, 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. > Alternatively, you could insist that a module *is* a schema for naming > purposes, with some extra

Re: support for CREATE MODULE

On Fri, Feb 4, 2022 at 5:12 PM Tom Lane wrote: > > On the whole I'm kind of allergic to inventing an entire new concept > that has as much overlap with extensions as modules seem to. I'd > rather try to understand what functional requirements we're missing > and see if we can add them to

Re: support for CREATE MODULE

Alvaro Herrera writes: > He said: >> [ This patch ] [...] allows for 3-part (or 4 with the database name) >> naming of objects within the module. > He then showed the following example: >> CREATE SCHEMA foo; >> CREATE MODULE foo.bar >> CREATE FUNCTION hello() [...] >> SELECT foo.bar.hello();

Re: support for CREATE MODULE

On 2022-Feb-04, Swaha Miller wrote: > 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.) I don't agree that what he proposed was similar to

Re: support for CREATE MODULE

On Fri, Feb 4, 2022 at 10:46 AM Bruce Momjian wrote: > On Wed, Feb 2, 2022 at 06:28:30PM -0800, Swaha Miller wrote: > > Hi, > > > > I'm following up from Jim's POC for adding MODULE to PostgreSQL. [1] > > > > My proposal implements modules as schema objects to be stored in a new > > system

Re: support for CREATE MODULE

On Thu, Feb 3, 2022 at 5:42 PM Alvaro Herrera 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

Re: support for CREATE MODULE

On Wed, Feb 2, 2022 at 06:28:30PM -0800, Swaha Miller wrote: > Hi, > > I'm following up from Jim's POC for adding MODULE to PostgreSQL. [1] > > My proposal implements modules as schema objects to be stored in a new > system catalog pg_module with new syntax for CREATE [OR REPLACE] MODULE, You

Re: support for CREATE MODULE

Hi, On Thu, Feb 03, 2022 at 10:42:32PM -0300, Alvaro Herrera 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

Re: support for CREATE MODULE

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

Re: support for CREATE MODULE

čt 3. 2. 2022 v 20:21 odesílatel Swaha Miller napsal: > Thank you for the feedback Pavel and Julien. I'll try to explain some of > the issues and points you raise to the best of my understanding. > > The reason for modules is that it would serve as an organizational unit > that can allow setting

Re: support for CREATE MODULE

Thank you for the feedback Pavel and Julien. I'll try to explain some of the issues and points you raise to the best of my understanding. The reason for modules is that it would serve as an organizational unit that can allow setting permissions on those units. So, for example, all functions in a

Re: support for CREATE MODULE

čt 3. 2. 2022 v 5:46 odesílatel Julien Rouhaud napsal: > Hi, > > On Thu, Feb 03, 2022 at 05:25:27AM +0100, Pavel Stehule wrote: > > > > čt 3. 2. 2022 v 3:28 odesílatel Swaha Miller > > napsal: > > > > > Hi, > > > > > > I'm following up from Jim's POC for adding MODULE to PostgreSQL. [1] > > > >

Re: support for CREATE MODULE

Hi, On Thu, Feb 03, 2022 at 05:25:27AM +0100, Pavel Stehule wrote: > > čt 3. 2. 2022 v 3:28 odesílatel Swaha Miller > napsal: > > > Hi, > > > > I'm following up from Jim's POC for adding MODULE to PostgreSQL. [1] > > > > My proposal implements modules as schema objects to be stored in a new >

Re: support for CREATE MODULE

Hi čt 3. 2. 2022 v 3:28 odesílatel Swaha Miller napsal: > Hi, > > I'm following up from Jim's POC for adding MODULE to PostgreSQL. [1] > > My proposal implements modules as schema objects to be stored in a new > system catalog pg_module with new syntax for CREATE [OR REPLACE] MODULE, > ALTER

Re: Support for CREATE MODULE?

Hi st 2. 6. 2021 v 15:39 odesílatel Jim Mlodgenski napsal: > Working with users over the years, some have large libraries of server > side code sometimes consisting of 100k+ lines of code over 1000+ functions > and procedures. This usually comes from a migration of a commercial > database like

Re: Support for CREATE MODULE?

On Thu, Jun 3, 2021 at 8:49 AM Peter Eisentraut wrote: > Given that, as you said, the concept of modules is in the SQL standard, > there is surely some guidance in there about how this is supposed to > affect name resolution. So let's start with that. Maybe we won't like > it in the end or

Re: Support for CREATE MODULE?

On 02.06.21 16:43, Jim Mlodgenski wrote: It's already quite hard to tell which part of a multiply.qualified.name is which, given that SQL says that you can optionally put a "catalog" (database) name in front of the others. I really doubt there is a way to shoehorn sub-schemas in there without

Re: Support for CREATE MODULE?

On 2021-Jun-02, Jim Mlodgenski wrote: > Attached is a POC patch for modules. I modeled it as a sub-schema because > that is more what it seems like to me. It adds additional columns to > pg_namespace and allows for 3-part (or 4 with the database name) naming > of objects within the module. This

Re: Support for CREATE MODULE?

On Wed, Jun 2, 2021, at 16:43, Jim Mlodgenski wrote: > On Wed, Jun 2, 2021 at 9:58 AM Tom Lane > wrote: > > I wonder whether it'd be better to consider modules as a kind of > > extension, or at least things with the same sort of ownership relations > > as extensions

Re: Support for CREATE MODULE?

Bruce Momjian writes: > If we go in this direction, I assume we would just disallow a schema > name matching the database name. That seems quite impossible to enforce. regression=# create database d1; CREATE DATABASE regression=# alter database d1 rename to d2; ALTER DATABASE The system had no

Re: Support for CREATE MODULE?

On 6/2/21 10:43 AM, Jim Mlodgenski wrote: On Wed, Jun 2, 2021 at 9:58 AM Tom Lane wrote: I wonder whether it'd be better to consider modules as a kind of extension, or at least things with the same sort of ownership relations as extensions have. That would solve the problem of associating

Re: Support for CREATE MODULE?

On Wed, Jun 2, 2021 at 10:43:10AM -0400, Jim Mlodgenski wrote: > On Wed, Jun 2, 2021 at 9:58 AM Tom Lane wrote: > > > > In the first place, what do you think the primary key of pg_namespace is > > now? > > In the patch the unique constraint is (nspname, nspnamespace) which is > certainly

Re: Support for CREATE MODULE?

On Wed, Jun 2, 2021 at 9:58 AM Tom Lane wrote: > > In the first place, what do you think the primary key of pg_namespace is now? In the patch the unique constraint is (nspname, nspnamespace) which is certainly awkward. I initially went down the pg_module route to avoid adding another catalog,

Re: Support for CREATE MODULE?

Jim Mlodgenski writes: > Questions > - Do we want to add module support? Certainly many people have asked for that, or things like that. > - If we do, should it be implemented as a type of namespace or should it > be its own object type that lives in something like pg_module? While I didn't

Support for CREATE MODULE?

Working with users over the years, some have large libraries of server side code sometimes consisting of 100k+ lines of code over 1000+ functions and procedures. This usually comes from a migration of a commercial database like Oracle where it was best practice to put all of your business logic