Re: Add Postgres module info

From: Yurii Rashkovskii <yrashk(at)omnigres(dot)com>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add Postgres module info
Date: 2024-12-27 05:10:48
Message-ID: CAG=VW15KoiU+rSTWf4JatO57Med1-H3gqDPQxKVNV6pj8Lmqgw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 27, 2024 at 8:34 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:

> On 12/24/24 10:42, Yurii Rashkovskii wrote:
> > On Mon, Dec 16, 2024 at 12:02 PM Andrei Lepikhov <lepihov(at)gmail(dot)com
> > I've reviewed the patch, and it is great that you support more flexible
> > versioning now. I am just wondering a bit about the case where `minfo-
> > >name` can be `NULL` but `minfo->version` isn't, or where both are
> > `NULL` – should we skip any of these?
> Depends. I wrote code that way so as not to restrict a maintainer by
> initialising all the fields; remember, it may grow in the future.
> But I am open to changing that logic. Do you have any specific rule on
> which fields may be empty and that must be initialised? Do you think all
> fields maintainer must fill with non-zero-length constants?

After more thinking, I'll concede that not doing anything about null
metadata is probably better – making the function always return the list of
modules, regardless of whether any metadata was supplied. It's beneficial
to be able to get the entire list of modules regardless of metadata.

The only other minor concern I have left is that some modules might have a
clashing name or may change the name during the extension's lifetime
(happened to some of my early work). Providing a permanent identifier and a
human-digestible identifier may be worth it.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2024-12-27 06:00:06 Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility.
Previous Message Michael Paquier 2024-12-27 04:42:22 Re: date_trunc invalid units with infinite value