On Jul 31, 2024, at 05:27, Peter Eisentraut wrote:
> Well, nobody has protested against what we wrote, so I have committed it.
Excellent, thank you!
D
On 19.07.24 16:10, David E. Wheeler wrote:
On Jun 27, 2024, at 18:07, David E. Wheeler wrote:
Minor nit - misspelled “considerd"
Thank you, Jeremy. V3 attached.
Rebase on 5784a49 attached. I presume this topic needs quite a bit of review
and consensus from the committers more generally.
On Jun 27, 2024, at 18:07, David E. Wheeler wrote:
>> Minor nit - misspelled “considerd"
>
> Thank you, Jeremy. V3 attached.
Rebase on 5784a49 attached. I presume this topic needs quite a bit of review
and consensus from the committers more generally.
Best,
David
v4-0001-Add-API-an-ABI-gu
On Jun 27, 2024, at 17:48, Jeremy Schneider wrote:
> Minor nit - misspelled “considerd"
Thank you, Jeremy. V3 attached.
Best,
David
v3-0001-Add-API-an-ABI-guidance-to-the-C-language-docs.patch
Description: Binary data
On 6/26/24 12:23 PM, David E. Wheeler wrote:
> On Jun 26, 2024, at 15:20, David E. Wheeler wrote:
>
>> CF: https://commitfest.postgresql.org/48/5080/
>> PR: https://github.com/theory/postgres/pull/6
>
> Aaaand v2 without the unnecessary formatting of unrelated documentation 🤦🏻♂️.
Minor nit - m
On Jun 26, 2024, at 15:20, David E. Wheeler wrote:
> CF: https://commitfest.postgresql.org/48/5080/
> PR: https://github.com/theory/postgres/pull/6
Aaaand v2 without the unnecessary formatting of unrelated documentation 🤦🏻♂️.
Best,
David
v2-0001-Add-API-an-ABI-guidance-to-the-C-language-do
On Jun 26, 2024, at 15:14, David E. Wheeler wrote:
> Okay here’s a patch that adds the proposed API and ABI guidance to the C
> Language docs. The content is the same as Peter proposed, with some light
> copy-editing.
CF: https://commitfest.postgresql.org/48/5080/
PR: https://github.com/theory
On Jun 25, 2024, at 13:55, David E. Wheeler wrote:
> Oh man this is fantastic, thank you! I’d be more than happy to just turn this
> into a patch. But where should it go? Upthread I assumed xfunc.sgml, and
> still think that’s a likely candidate. Perhaps I’ll just start there ---
> unless some
On Jun 26, 2024, at 04:48, Laurenz Albe wrote:
> Perhaps such information should go somewhere here:
> https://www.postgresql.org/support/versioning/
This seems deeper and more detailed than what’s there now, but I can certainly
imagine wanting to include this policy on the web site. That said,
On Tue, 2024-06-25 at 13:55 -0400, David E. Wheeler wrote:
> On Jun 25, 2024, at 7:33 AM, Peter Eisentraut wrote:
>
> > I took at a stab at this, using some of your text, but discussing API and
> > ABI separately.
>
> Oh man this is fantastic, thank you! I’d be more than happy to just turn this
On Jun 25, 2024, at 7:33 AM, Peter Eisentraut wrote:
> I took at a stab at this, using some of your text, but discussing API and ABI
> separately.
Oh man this is fantastic, thank you! I’d be more than happy to just turn this
into a patch. But where should it go? Upthread I assumed xfunc.sgml,
Peter Eisentraut writes:
> On 24.06.24 22:26, David E. Wheeler wrote:
>>> But now we're talking about API. That might be subject of another
>> document or another section in this one, but it seems confusing to mix
>> this with the ABI discussion.
>> Hrm. They’re super closely-related in my mind,
On 24.06.24 22:26, David E. Wheeler wrote:
But now we're talking about API. That might be subject of another document or
another section in this one, but it seems confusing to mix this with the ABI
discussion.
Hrm. They’re super closely-related in my mind, as an extension developer. I
need t
On Jun 19, 2024, at 05:41, Peter Eisentraut wrote:
> This is probably a bit confusing. This might as well mean client application
> code against libpq. Better something like "server plugin code that uses the
> PostgreSQL server APIs".
That works.
> But now we're talking about API. That mig
On Jun 24, 2024, at 14:51, Robert Haas wrote:
> I suppose that it's true that we try to avoid gratuitous breakage, but
> I feel like it would be weird to document that.
I see how that can seem weird to a committer deeply familiar with the
development process and how things happen. But people ou
On Jun 19, 2024, at 05:42, Peter Eisentraut wrote:
>>> https://postgr.es/m/CAH2-Wzm-W6hSn71sUkz0Rem=qdeu7tnfmc7_jg2djrlfef_...@mail.gmail.com
>>>
>>> Theoretically anybody can do this themselves. In practice they don't.
>>> So something as simple as providing automated reports about ABI
>>> chan
On Mon, Jun 17, 2024 at 6:38 PM David E. Wheeler wrote:
> Is it? ISTM that there is the intention not to break things that don’t need
> to be broken, though that doesn’t rule out interface improvements.
I suppose that it's true that we try to avoid gratuitous breakage, but
I feel like it would b
On 18.06.24 00:40, David E. Wheeler wrote:
On Jun 12, 2024, at 11:57, Peter Geoghegan wrote:
That having been said, it would be useful if there was a community web
resource for this -- something akin to coverage.postgresql.org, but
with differential ABI breakage reports. You can see an example
On 18.06.24 00:37, David E. Wheeler wrote:
ABI Policy
==
The PostgreSQL core team maintains two application binary interface (ABI)
guarantees: one for major releases and one for minor releases.
Major Releases
--
Applications that use the PostgreSQL APIs
This is probably
On 03/06/2024 21:21, David E. Wheeler wrote:
On Jun 3, 2024, at 14:58, Andres Freund wrote:
Hi,
Hello Andres.
Are there notes for the session?
Yes, but not posted yet. Here’s what Andreas 'ads' Scherbaum sent me for that
bit of the conversation:
* Core is focused on core ABI stability
On Jun 12, 2024, at 11:57, Peter Geoghegan wrote:
> That having been said, it would be useful if there was a community web
> resource for this -- something akin to coverage.postgresql.org, but
> with differential ABI breakage reports. You can see an example report
> here:
>
> https://postgr.es/m
On Jun 12, 2024, at 11:30, Peter Geoghegan wrote:
> I'm a little surprised that we don't seem to have all that many
> problems with ABI breakage, though. Although we theoretically have a
> huge number of APIs that extension authors might choose to use, that
> isn't really true in practical terms.
On Jun 12, 2024, at 11:20, Andres Freund wrote:
>> The PostgreSQL core team maintains two application binary interface (ABI)
>> guarantees: one for major releases and one for minor releases.
>
> I.e. for major versions it's "there is none"?
Is it? ISTM that there is the intention not to break
On 12.06.24 16:47, Robert Haas wrote:
On Mon, Jun 3, 2024 at 3:39 PM Tom Lane wrote:
Me either. There are degrees of ABI compatibility
Exactly this!
What I think would be useful to document is our usual practices e.g.
adding new struct members at the end of structs, trying to avoid
changing
On Tue, Jun 11, 2024 at 10:55 AM David E. Wheeler wrote:
> Right, it’s just that extension authors could use some notification that such
> a change is coming so they can update their code, if necessary.
In general our strategy around ABI breaks is to avoid them whenever
possible. We also make th
On Mon, Jun 3, 2024 at 3:38 PM Tom Lane wrote:
> > Thus I am not really on board with this statement as-is.
>
> Me either. There are degrees of ABI compatibility, and we'll choose
> the least invasive way, but it's seldom the case that no conceivable
> extension will be broken. For example, if w
Hi,
On 2024-06-12 14:58:04 +0200, Jelte Fennema-Nio wrote:
> On Wed, 12 Jun 2024 at 14:44, Peter Eisentraut wrote:
> > I think since around 6 years ago we have been much more vigilant about
> > avoiding ABI breaks. So if there aren't any more recent examples of
> > breakage, then maybe that was
On 2024-06-11 10:55:38 -0400, David E. Wheeler wrote:
> ABI Policy
> ==
>
> The PostgreSQL core team maintains two application binary interface (ABI)
> guarantees: one for major releases and one for minor releases.
I.e. for major versions it's "there is none"?
> Major Releases
> ---
On Jun 12, 2024, at 10:47, Robert Haas wrote:
> What I think would be useful to document is our usual practices e.g.
> adding new struct members at the end of structs, trying to avoid
> changing public function signatures. If we document promises to
> extension authors, I don't know how much diff
On Mon, Jun 3, 2024 at 3:39 PM Tom Lane wrote:
> Me either. There are degrees of ABI compatibility
Exactly this!
What I think would be useful to document is our usual practices e.g.
adding new struct members at the end of structs, trying to avoid
changing public function signatures. If we docum
On Jun 12, 2024, at 8:58 AM, Jelte Fennema-Nio wrote:
> While not strictly an ABI break I guess, the backport of 32d5a4974c81
> broke building Citus against 13.10 and 14.7[1].
>
> [1]: https://github.com/citusdata/citus/pull/6711
Interesting one. We might want to advise projects to use deferent
On Jun 12, 2024, at 8:43 AM, Peter Eisentraut wrote:
>> Right, it’s just that extension authors could use some notification that
>> such a change is coming so they can update their code, if necessary.
>
> I think since around 6 years ago we have been much more vigilant about
> avoiding ABI bre
On Wed, 12 Jun 2024 at 14:44, Peter Eisentraut wrote:
> I think since around 6 years ago we have been much more vigilant about
> avoiding ABI breaks. So if there aren't any more recent examples of
> breakage, then maybe that was ultimately successful, and the upshot is,
> continue to be vigilant
On 11.06.24 16:55, David E. Wheeler wrote:
On Jun 10, 2024, at 15:39, Andres Freund wrote:
That's 6 years ago, not sure we can really learn that much from that.
And it's not like it's actually impossible, #ifdefs aren't great, but they are
better than nothing.
Right, it’s just that extensio
On Jun 10, 2024, at 15:39, Andres Freund wrote:
> That's 6 years ago, not sure we can really learn that much from that.
>
> And it's not like it's actually impossible, #ifdefs aren't great, but they are
> better than nothing.
Right, it’s just that extension authors could use some notification t
Hi,
On 2024-06-10 15:05:32 -0400, David E. Wheeler wrote:
> > An API break in PostgreSQL 10.4 and 9.6.9 makes it impossible
> > to use these versions: the "extract_actual_join_clauses" function
> > gained an additional parameter.
>
> The 10.4 commit is 68fab04, and it does indeed add a new functi
On Jun 4, 2024, at 03:18, Peter Eisentraut wrote:
> This could possibly be avoided by renaming the symbol in backbranches. Maybe
> something like
>
> #define InitResultRelInfo InitResultRelInfo2
>
> Then you'd get a specific error message when loading the module, rather than
> a crash.
That
On 04.06.24 02:11, Laurenz Albe wrote:
On Mon, 2024-06-03 at 15:38 -0400, Tom Lane wrote:
Andres Freund writes:
On 2024-06-03 14:43:17 -0400, David E. Wheeler wrote:
* The ABI is guaranteed to change only in backward compatible ways in minor
releases. If for some reason it doesn’t it’s a bug
On Mon, 2024-06-03 at 15:38 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-06-03 14:43:17 -0400, David E. Wheeler wrote:
> > > * The ABI is guaranteed to change only in backward compatible ways in
> > > minor
> > > releases. If for some reason it doesn’t it’s a bug that will need to b
On Jun 3, 2024, at 5:56 PM, Andres Freund wrote:
> I don't see how this would trigger random crashes.
>
> Unfortunately [4] doesn't seem to take me to a relevant message (pruned chat
> history?), so I can't infer more from that context.
You can use [4] to join the Slack (if you haven’t already)
Hi,
On 2024-06-03 15:21:04 -0400, David E. Wheeler wrote:
> > Extensions in general can do lots of stuff, guaranteeing that bug fixes
> > don't
> > cause any problems is just not feasible.
> >
> > It'd be interesting to see a few examples of actual minor-version-upgrade
> > extension breakages, s
> > I don't think it's common for such new-fields-in-padding to cause problems
> > when using an earlier minor PG version. For that the extension would need to
> > actually rely on the presence of the new field, but typically that'd not be
> > the case when we introduce a new field in a minor versi
Andres Freund writes:
> On 2024-06-03 14:43:17 -0400, David E. Wheeler wrote:
>> * The ABI is guaranteed to change only in backward compatible ways in minor
>> releases. If for some reason it doesn’t it’s a bug that will need to be
>> fixed.
> Thus I am not really on board with this statement as-
On Jun 3, 2024, at 14:58, Andres Freund wrote:
> Hi,
Hello Andres.
> Are there notes for the session?
Yes, but not posted yet. Here’s what Andreas 'ads' Scherbaum sent me for that
bit of the conversation:
* Core is focused on core ABI stability
* David: No "statement of stability" in Cor
Hi,
On 2024-06-03 14:43:17 -0400, David E. Wheeler wrote:
> At the PGConf Unconference session on improving extension support in core,
> we talked quite a bit about the recent anxiety among extension developers
> about a lack of an ABI compatibility guarantee in Postgres.
Are there notes for the
45 matches
Mail list logo
