I have committed this patch as posted.
Peter Eisentraut writes:
>> On Wed, Oct 13, 2021 at 12:50:38PM -0400, Robert Haas wrote:
>>> Would it be reasonable to consider something similar for the control
>>> file, for the benefit of distributions that are not the same on disk?
> The catalog version already serves this purpose.
We
On 19.11.21 08:58, Michael Paquier wrote:
On Wed, Oct 13, 2021 at 12:50:38PM -0400, Robert Haas wrote:
I'm not a different vendor, but I do work on different code than you
do, and I like this. Advanced Server accidentally dodges this problem
at present by shipping with a different FUNC_MAX_ARGS
On Wed, Oct 13, 2021 at 12:50:38PM -0400, Robert Haas wrote:
> I'm not a different vendor, but I do work on different code than you
> do, and I like this. Advanced Server accidentally dodges this problem
> at present by shipping with a different FUNC_MAX_ARGS value, but this
> is much cleaner.
I
On Tue, Oct 12, 2021 at 8:13 AM Peter Eisentraut
wrote:
> So here is a patch. This does what I had in mind as a use case.
> Obviously, the naming and wording can be tuned. Input from other
> vendors is welcome.
I'm not a different vendor, but I do work on different code than you
do, and I like
So here is a patch. This does what I had in mind as a use case.
Obviously, the naming and wording can be tuned. Input from other
vendors is welcome.
From 837680c2195a04bf1f1ecf567fadc3a3d69087fa Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 12 Oct 2021 14:08:10 +0200
Subject:
On 07.10.21 21:15, Tom Lane wrote:
Chapman Flack writes:
On 10/07/21 12:42, Tom Lane wrote:
Can we make the addition be a string not a number, so that we
could include something more useful than "1234" in the error
message?
Just using a string like "EDB v" + something would probably rule
Chapman Flack writes:
> On 10/07/21 12:42, Tom Lane wrote:
>> Can we make the addition be a string not a number, so that we
>> could include something more useful than "1234" in the error
>> message?
> Just using a string like "EDB v" + something would probably rule out
> collisions in practice.
On 10/07/21 12:42, Tom Lane wrote:
> Can we make the addition be a string not a number, so that we
> could include something more useful than "1234" in the error
> message?
I was wondering the same thing, just to sidestep the "who hands out IDs"
question.
Just using a string like "EDB v" +
Andres Freund writes:
> On October 7, 2021 8:49:57 AM PDT, Tom Lane
>> I'm also kind of unclear on why we need to do anything about this
>> in the community version. If someone has forked PG and changed
>> APIs to the extent that extensions are unlikely to work, there's
>> not much stopping
Hi,
On October 7, 2021 8:49:57 AM PDT, Tom Lane
>I'm also kind of unclear on why we need to do anything about this
>in the community version. If someone has forked PG and changed
>APIs to the extent that extensions are unlikely to work, there's
>not much stopping them from also making the
Peter Eisentraut writes:
> 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.
Who would hand out these magic numbers?
If the answer is "choose a random one, it probably
čt 7. 10. 2021 v 11:28 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.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
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
14 matches
Mail list logo
