Re: Add Postgres module info

On Wed, Mar 26, 2025 at 8:17 PM Tom Lane wrote: > Yurii Rashkovskii writes: > >> Can you propose a specific change to clean it up? I wanted to write > >> just "PG_MODULE_MAGIC_DATA()", but I'm not sure that's valid C either. > > > I was thinking about passing `.name = NULL, .version = NULL` ins

Re: Add Postgres module info

Yurii Rashkovskii writes: > Would something like this work? Works for me; pushed. regards, tom lane

Re: Add Postgres module info

Yurii Rashkovskii writes: > This recent patch is great but causes a small problem. It mixes designated > and non-designated initializers, specifically in `PG_MODULE_MAGIC_DATA(0)`. Ugh. I felt a bit itchy about that, but my compiler wasn't complaining... Can you propose a specific change to cle

Re: Add Postgres module info

Yurii Rashkovskii writes: >> Can you propose a specific change to clean it up? I wanted to write >> just "PG_MODULE_MAGIC_DATA()", but I'm not sure that's valid C either. > I was thinking about passing `.name = NULL, .version = NULL` instead of > `0`—do you have any reservations about this? If

Re: Add Postgres module info

On Wed, Mar 26, 2025 at 7:45 PM Tom Lane wrote: > > This recent patch is great but causes a small problem. It mixes > designated > > and non-designated initializers, specifically in > `PG_MODULE_MAGIC_DATA(0)`. > > Ugh. I felt a bit itchy about that, but my compiler wasn't > complaining... > Th

Re: Add Postgres module info

Hi Tom, This recent patch is great but causes a small problem. It mixes designated and non-designated initializers, specifically in `PG_MODULE_MAGIC_DATA(0)`. While this is permissible in C, when imported in C++ code (in extern "C"), it causes GCC to emit an error: `either all initializer clauses

Re: Add Postgres module info

Hearing no further discussion, I've pushed this. regards, tom lane

Re: Add Postgres module info

Andrei Lepikhov writes: > On 3/22/25 23:49, Tom Lane wrote: >> * It is not clear to me what permission restrictions we should put >> on pg_get_loaded_modules, ... > I vote for the idea of stripping the full path to just a filename. Works for me. v7 attached does it that way. >> * I'm not happy

Re: Add Postgres module info

"Euler Taveira" writes: > I think those modules without control file, it is natural to use PG_VERSION. > However, I'm concerned that users can confuse the version if we provide > PG_VERSION as version and the extension catalog says something different. Maybe, but the values will be sufficiently d

Re: Add Postgres module info

On Mon, Mar 24, 2025, at 12:54 PM, Tom Lane wrote: > Robert Haas writes: > > It looks reasonable to me. I am a bit worried that using PG_VERSION as > > the version string is going to feel like the wrong thing at some > > stage, but I can't really say why, and I think it's better to do > > somethin

Re: Add Postgres module info

On Mon, Mar 24, 2025 at 11:54 AM Tom Lane wrote: > If somebody thinks of a better idea and is willing to do the legwork > to make it happen, we can surely change to something else later on. > Or invent another field with different semantics, or whatever. Yeah, my thoughts exactly. -- Robert Haa

Re: Add Postgres module info

Robert Haas writes: > It looks reasonable to me. I am a bit worried that using PG_VERSION as > the version string is going to feel like the wrong thing at some > stage, but I can't really say why, and I think it's better to do > something now and maybe have to revise it later than to do nothing no

Re: Add Postgres module info

On Sun, Mar 23, 2025 at 3:10 PM Tom Lane wrote: > I think this version is ready to commit, if there are not objections > to the decisions mentioned above. It looks reasonable to me. I am a bit worried that using PG_VERSION as the version string is going to feel like the wrong thing at some stage,

Re: Add Postgres module info

On 3/23/25 20:10, Tom Lane wrote: Andrei Lepikhov writes: On 3/22/25 23:49, Tom Lane wrote: * It is not clear to me what permission restrictions we should put on pg_get_loaded_modules, ... I vote for the idea of stripping the full path to just a filename. Works for me. v7 attached does i

Re: Add Postgres module info

On 3/22/25 23:49, Tom Lane wrote: I spent awhile reviewing the v5 patch, and here's a proposed v6. Some notes: * I didn't like depending on offsetof(Pg_magic_struct, module_extra) to determine which parts of the struct are checked for compatibility. It just seems way too easy to break that with

Re: Add Postgres module info

I spent awhile reviewing the v5 patch, and here's a proposed v6. Some notes: * I didn't like depending on offsetof(Pg_magic_struct, module_extra) to determine which parts of the struct are checked for compatibility. It just seems way too easy to break that with careless insertion of new fields, an

Re: Add Postgres module info

On 7/3/2025 16:56, Andrei Lepikhov wrote: On 2/3/2025 20:35, Andrei Lepikhov wrote: On 17/2/2025 04:00, Michael Paquier wrote: No documentation provided. Ok, I haven't been sure this idea has a chance to be committed. I will introduce the docs in the next version. This is a new version with bu

Re: Add Postgres module info

On 2/3/2025 20:35, Andrei Lepikhov wrote: On 17/2/2025 04:00, Michael Paquier wrote: No documentation provided. Ok, I haven't been sure this idea has a chance to be committed. I will introduce the docs in the next version. This is a new version with bug fixes. Also, use TAP tests instead of re

Re: Add Postgres module info

On 17/2/2025 04:00, Michael Paquier wrote: On Mon, Feb 17, 2025 at 03:41:56AM +0200, Alexander Korotkov wrote: 1) Is it intended to switch all in-core libraries to use PG_MODULE_MAGIC_EXT()? 2) Once we have module version information, it looks natural to specify the required version for dependan

Re: Add Postgres module info

On 17/2/2025 02:41, Alexander Korotkov wrote: On Mon, Dec 16, 2024 at 7:02 AM Andrei Lepikhov wrote: On 12/13/24 10:17, Tom Lane wrote: There's nothing stopping a field of the magic block from being a "const char *" pointer to a string literal. Ok, See v.2 in attachment. Generally, the patc

Re: Add Postgres module info

On Mon, Feb 17, 2025 at 03:41:56AM +0200, Alexander Korotkov wrote: > 1) Is it intended to switch all in-core libraries to use > PG_MODULE_MAGIC_EXT()? > 2) Once we have module version information, it looks natural to > specify the required version for dependant objects, e.g. SQL-funcions > implem

Re: Add Postgres module info

Hi, Andrei! On Mon, Dec 16, 2024 at 7:02 AM Andrei Lepikhov wrote: >ly > On 12/13/24 10:17, Tom Lane wrote: > > Andrei Lepikhov writes: > >> On 12/12/24 21:02, Yurii Rashkovskii wrote: > >>> 2. Any reasons to dictate MAJ.MIN format? With semantic versioning > >>> abound, it's rather common to us

Re: Add Postgres module info

On Dec 26, 2024, at 20:09, Andrei Lepikhov wrote: > We intentionally wrote a library, not an extension. According to user usage > and upgrade patterns, it works across the whole instance and in any database > or locally in a single backend and ends its impact at the end of its life. The same i

Re: Add Postgres module info

On Fri, Dec 27, 2024 at 8:34 AM Andrei Lepikhov wrote: > On 12/24/24 10:42, Yurii Rashkovskii wrote: > > On Mon, Dec 16, 2024 at 12:02 PM Andrei Lepikhov > 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 `

Re: Add Postgres module info

On 12/24/24 10:42, Yurii Rashkovskii wrote: On Mon, Dec 16, 2024 at 12:02 PM Andrei Lepikhov 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 b

Re: Add Postgres module info

On 12/27/24 01:26, David Wheeler wrote: On Mon, Dec 23, 2024, at 8:49 PM, Andrei Lepikhov wrote: Looking into the control file, I see that most parameters are unnecessary for the library. Why do we have to maintain this file? Well, either way you have to load the extension, either CREATE EXTEN

Re: Add Postgres module info

On Mon, Dec 23, 2024, at 8:49 PM, Andrei Lepikhov wrote: > Looking into the control file, I see that most parameters are > unnecessary for the library. Why do we have to maintain this file? Most of the parameters apply to SQL extensions. > The 'CREATE EXTENSION' statement would have made sense

Re: Add Postgres module info

On 12/23/24 17:26, David E. Wheeler wrote: > On Dec 23, 2024, at 15:17, Tom Lane wrote: >> How would that work for extensions where the C code is intentionally >> supporting multiple versions of the SQL objects? > > I guess some people do that, eh? In that case it wouldn’t. A function pointer ra

Re: Add Postgres module info

On Mon, Dec 16, 2024 at 12:02 PM Andrei Lepikhov wrote: > On 12/13/24 10:17, Tom Lane wrote: > > Andrei Lepikhov writes: > >> On 12/12/24 21:02, Yurii Rashkovskii wrote: > >>> 2. Any reasons to dictate MAJ.MIN format? With semantic versioning > >>> abound, it's rather common to use MAJ.MIN.PATCH

Re: Add Postgres module info

On 12/24/24 02:23, David E. Wheeler wrote: On Dec 11, 2024, at 19:49, Euler Taveira wrote: FWIW, Id like to have some more information in there, without commenting on the specifics. +1 for the general idea. Same. I received some reports like [1] related to wal2json that people wants to o

Re: Add Postgres module info

On Dec 23, 2024, at 15:17, Tom Lane wrote: > How would that work for extensions where the C code is intentionally > supporting multiple versions of the SQL objects? I guess some people do that, eh? In that case it wouldn’t. D

Re: Add Postgres module info

"David E. Wheeler" writes: > Not a mutually-exclusive proposal, of course; I think it makes sense to have > metadata included in the binary itself. Would be useful to compare against > what CREATE EXTENSION thinks is the version and raising an error or warning > when they diverge. How would th

Re: Add Postgres module info

On Dec 11, 2024, at 19:49, Euler Taveira wrote: >> FWIW, Id like to have some more information in there, without commenting on >> the specifics. > > +1 for the general idea. Same. > I received some reports like [1] related to wal2json > that people wants to obtain the output plugin version. Si

Re: Add Postgres module info

On 12/13/24 10:17, Tom Lane wrote: Andrei Lepikhov writes: On 12/12/24 21:02, Yurii Rashkovskii wrote: 2. Any reasons to dictate MAJ.MIN format? With semantic versioning abound, it's rather common to use MAJ.MIN.PATCH. Okay, thanks; that's a good catch. I wonder how to follow these rules wi

Re: Add Postgres module info

Andrei Lepikhov writes: > On 12/12/24 21:02, Yurii Rashkovskii wrote: >> 2. Any reasons to dictate MAJ.MIN format? With semantic versioning >> abound, it's rather common to use MAJ.MIN.PATCH. > Okay, thanks; that's a good catch. I wonder how to follow these rules > with a static fixed-sized str

Re: Add Postgres module info

On 12/12/24 21:02, Yurii Rashkovskii wrote: On Thu, Dec 12, 2024 at 3:41 PM Andrei Lepikhov > wrote: On 12/12/24 08:36, Tom Lane wrote: > Andrei Lepikhov mailto:lepi...@gmail.com>> writes: >> It makes sense. But I want to clarify that I avoided changin

Re: Add Postgres module info

Andres Freund writes: > On 2024-12-12 11:35:56 +0700, Andrei Lepikhov wrote: >> I want to say that 'cannot unload libraries' is a negative outcome of the >> architecture. It would be better to invent something like PG_unregister, >> allowing libraries to at least return a hook routine call back to

Re: Add Postgres module info

Hi, On 2024-12-12 11:35:56 +0700, Andrei Lepikhov wrote: > On 12/12/24 10:44, Michael Paquier wrote: > > On Wed, Dec 11, 2024 at 10:39:38PM -0500, Tom Lane wrote: > > > Michael Paquier writes: > > > > Presumably, > > > > the extra tracking can be done in dfmgr.c with more fields added to > > > >

Re: Add Postgres module info

On Thu, Dec 12, 2024 at 3:41 PM Andrei Lepikhov wrote: > On 12/12/24 08:36, Tom Lane wrote: > > Andrei Lepikhov writes: > >> It makes sense. But I want to clarify that I avoided changing > >> PG_MODULE_MAGIC because the newly introduced structure has a totally > >> different purpose and usage lo

Re: Add Postgres module info

On 12/12/24 08:36, Tom Lane wrote: Andrei Lepikhov writes: It makes sense. But I want to clarify that I avoided changing PG_MODULE_MAGIC because the newly introduced structure has a totally different purpose and usage logic: the struct is designed to check compatibility, but module info isn't c

Re: Add Postgres module info

On 12/12/24 10:44, Michael Paquier wrote: On Wed, Dec 11, 2024 at 10:39:38PM -0500, Tom Lane wrote: Michael Paquier writes: Presumably, the extra tracking can be done in dfmgr.c with more fields added to DynamicFileList to track the information involved. I wouldn't add any overhead to the no

Re: Add Postgres module info

On Wed, Dec 11, 2024 at 10:39:38PM -0500, Tom Lane wrote: > Michael Paquier writes: >> Presumably, >> the extra tracking can be done in dfmgr.c with more fields added to >> DynamicFileList to track the information involved. > > I wouldn't add any overhead to the normal case for this. Couldn't >

Re: Add Postgres module info

Michael Paquier writes: > On Wed, Dec 11, 2024 at 08:34:28PM -0500, Tom Lane wrote: >> What would you foresee as the SQL API for inspecting a module that's >> not tied to an extension? > Rather than a function that can be called with a specific module name > in input, invent a new system SRF func

Re: Add Postgres module info

On Wed, Dec 11, 2024 at 08:34:28PM -0500, Tom Lane wrote: > "Euler Taveira" writes: >> +1 for the general idea. I received some reports like [1] related to wal2json >> that people wants to obtain the output plugin version. Since it is not >> installed >> via CREATE EXTENSION, it is not possible t

Re: Add Postgres module info

Andrei Lepikhov writes: > It makes sense. But I want to clarify that I avoided changing > PG_MODULE_MAGIC because the newly introduced structure has a totally > different purpose and usage logic: the struct is designed to check > compatibility, but module info isn't connected to the core versio

Re: Add Postgres module info

"Euler Taveira" writes: > +1 for the general idea. I received some reports like [1] related to wal2json > that people wants to obtain the output plugin version. Since it is not > installed > via CREATE EXTENSION, it is not possible to detect what version is installed, > hence, some tools cannot h

Re: Add Postgres module info

On 12/12/2024 01:21, Tom Lane wrote: Andrei Lepikhov writes: I would like to propose the module_info structure, which aims to let extension maintainers sew some data into the binary file. Being included in the module code, this information remains unchanged and is available for reading by a bac

Re: Add Postgres module info

On Wed, Dec 11, 2024, at 4:26 PM, Andres Freund wrote: > On 2024-12-11 13:21:03 -0500, Tom Lane wrote: > > Andrei Lepikhov writes: > > > I would like to propose the module_info structure, which aims to let > > > extension maintainers sew some data into the binary file. Being included > > > in the

Re: Add Postgres module info

Andres Freund writes: > On 2024-12-11 13:21:03 -0500, Tom Lane wrote: >> There are a couple of ways that we could deal with the API >> seen by module authors: > To be future proof, I think it'd be good to declare the arguments as > designated initializers. E.g. like > PG_MODULE_MAGIC_EXT( > .v

Re: Add Postgres module info

Hi, On 2024-12-11 13:21:03 -0500, Tom Lane wrote: > Andrei Lepikhov writes: > > I would like to propose the module_info structure, which aims to let > > extension maintainers sew some data into the binary file. Being included > > in the module code, this information remains unchanged and is avai

Re: Add Postgres module info

Andrei Lepikhov writes: > I would like to propose the module_info structure, which aims to let > extension maintainers sew some data into the binary file. Being included > in the module code, this information remains unchanged and is available > for reading by a backend. I don't have much of a