Re: dfmgr additional ABI version fields

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dfmgr additional ABI version fields
Date: 2021-10-07 10:02:23
Message-ID: CAFj8pRB4Y_kvZrOi++2ak8uihp73NjZkAuk_C0fD_oj6tTCEkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

čt 7. 10. 2021 v 11:28 odesílatel Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> napsal:

> When producing a forked version of PostgreSQL, there is no
> straightforward way to enforce that users don't accidentally load
> modules built for the non-forked (standard, community) version. You can
> only distinguish by PostgreSQL major version and a few compile-time
> settings. (see internal_load_library(), Pg_magic_struct) Depending on
> the details, mixing and matching might even work, until it doesn't, so
> this is a bad experience.
>
> I'm thinking about adding two more int fields to Pg_magic_struct: a
> product or vendor magic number, and an ABI version that can be used
> freely within a product/vendor.
>
> Would anyone else have use for this? Any thoughts?
>

+1

Pavel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rajkumar Raghuwanshi 2021-10-07 10:34:52 Re: Multi-Column List Partitioning
Previous Message Shinya Kato 2021-10-07 09:59:38 Re: [PATCH] Added TRANSFORM FOR for COMMENT tab completion