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
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 |