Re: support for CREATE MODULE

From: Swaha Miller <swaha(dot)miller(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: support for CREATE MODULE
Date: 2022-02-10 16:53:15
Message-ID: CAPXknY7CosyXKxBr-VppKkwxS93xoQBjWJ3Afy=g3vzihe9Xcw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 4, 2022 at 3:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 concept of versions, plus pg_dump
> needs to act differently. That's probably enough semantic difference
> to justify using a separate word, even if we can share a lot of
> code infrastructure.
>

Then as a first cut for modules, could we add CREATE MODULE
syntax which adds an entry to pg_extension like CREATE EXTENSION
does? And also add a new column to pg_extension to distinguish
modules from extensions.

The three-part path name resolution for functions would remain the
same, nothing would need to change there because of modules.

Would that be an acceptable direction to go?

Swaha

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-02-10 17:00:16 Re: [RFC] building postgres with meson
Previous Message Bharath Rupireddy 2022-02-10 16:51:08 Re: can we add subscription TAP test option "vcregress subscriptioncheck" for MSVC builds?