Re: RFC: Extension Packaging & Lookup

> default). > > But maybe it’s not necessary? If there are no extensions by default, perhaps > it doesn’t matter? I ripped out the core/vendor/site stuff and have now published a fairly detailed RFC. https://justatheory.com/2024/11/rfc-extension-packaging-lookup/ What do you

Re: RFC: Extension Packaging & Lookup

On Nov 7, 2024, at 10:30, David E. Wheeler wrote: > Last week I tried to integrate all the ideas into this thread and the > previous[1] into a single proposal that attempts to work through all the > implications and issues. I’ve drafted it as a blog post[2] and plan to > publish it next week,

Re: RFC: Extension Packaging & Lookup

Hackers, On Oct 31, 2024, at 16:12, David E. Wheeler wrote: > I just thought of another one: Last week I tried to integrate all the ideas into this thread and the previous[1] into a single proposal that attempts to work through all the implications and issues. I’ve drafted it as a blog post[2

Re: RFC: Extension Packaging & Lookup

On Oct 31, 2024, at 15:41, David E. Wheeler wrote: > Other Options? > -- > > I kind of like Option 2, as it would allow us to eventually support > non-`CREATE EXTENSION` modules as extensions, too. I imagine distributing, > say `auto_explain` in an extension directory of its own, w

Re: RFC: Extension Packaging & Lookup

Fellow Humans, I’m working on an updated proposal with more detail, and more comprehensive. But I keep getting a bit caught up on this bit: On Oct 28, 2024, at 18:19, David E. Wheeler wrote: >> * Binary-only extensions might also be installed here; the difference is >> they have no control

Re: RFC: Extension Packaging & Lookup

On Oct 29, 2024, at 13:40, Tristan Partin wrote: > The backend would create the packages and publish them to the various > repositories. We would probably need to come up with a dependency manifest > that listed both build and runtime dependencies. > > This would need some massaging, and has v

Re: RFC: Extension Packaging & Lookup

Re: Tristan Partin > This would need some massaging, and has various caveats like require using a > well-known build system like PGXS or meson. There are probably security > implications that need to be worked through. The packaging team could maybe > have some burden lifted off their shoulders. S

Re: RFC: Extension Packaging & Lookup

On Tue Oct 29, 2024 at 12:03 PM CDT, David E. Wheeler wrote: On Oct 29, 2024, at 12:51, Christoph Berg wrote: I think this is where the whole idea of "provide binaries outside of deb/rpm" is just going to die. You are trying to reinvent a wheel that has been running well for decades, includin

Re: RFC: Extension Packaging & Lookup

On Oct 29, 2024, at 14:09, Christoph Berg wrote > So far, no one has approached me ("the packaging team") about which > problems I need solved with extensions (apart from the PGSHAREDIR > issue). > >> Is that something people would be interested in? As someone who writes >> software, I largely f

Re: RFC: Extension Packaging & Lookup

On Oct 29, 2024, at 14:03, Paul Ramsey wrote: > At that point you’re better off distributing the extension via the packaging > system, where you know that all the dependency versions line up correctly. Yeah. Perhaps it could be mitigated to some degree by requiring a minimum version of each de

Re: RFC: Extension Packaging & Lookup

> On Oct 29, 2024, at 10:55 AM, David E. Wheeler wrote: > >>> Relative rpaths as I have seen them are relative to the executable or >>> library in which they are defined (as far as I know, I’m not a dylib expert >>> by any stretch). The implication is that extension.so >>>

Re: RFC: Extension Packaging & Lookup

On Oct 29, 2024, at 13:16, Paul Ramsey wrote: > An apposite choice, since it not only demonstrates depending on a common > system library, it also demonstrates the way these things loop on each other, > as curl then depends on libssl, which postgres also depends on. Ooh, yeah, vicious! > Rela

Re: RFC: Extension Packaging & Lookup

> On Oct 29, 2024, at 10:09 AM, David E. Wheeler wrote: > > On Oct 29, 2024, at 12:23, Paul Ramsey wrote: > >> Thanks for this, David, > > 🤘🏻 > >> This of course is the area that worries the heck out of me, as someone with >> extensions that includes not just single system dependencies but

Re: RFC: Extension Packaging & Lookup

On Oct 29, 2024, at 12:23, Paul Ramsey wrote: > Question for the more knowledgable, how are binary distribution systems like > Conda and others shipping DLLs such that different packages don’t clobber > each other? I’m not familiar with Conda, but from its docs[1], it seems to rely on a value

Re: RFC: Extension Packaging & Lookup

On Oct 29, 2024, at 13:03, David E. Wheeler wrote: > That’s fine for Linux, but more challenging for macOS and Windows. It’s also > an issue that the apt and yum repositories, while having a lot of stuff, > don’t have all extensions. Sorry, I think I was too quick to respond there. To the degr

Re: RFC: Extension Packaging & Lookup

On Oct 29, 2024, at 12:23, Paul Ramsey wrote: > Thanks for this, David, 🤘🏻 > This of course is the area that worries the heck out of me, as someone with > extensions that includes not just single system dependencies but long chains > of them (depending on GDAL draws in a huge tree). Yeah. I

Re: RFC: Extension Packaging & Lookup

On Oct 29, 2024, at 12:51, Christoph Berg wrote: > I think this is where the whole idea of "provide binaries outside of > deb/rpm" is just going to die. You are trying to reinvent a wheel that > has been running well for decades, including lots of production > systems. I don't know anyone who wou

Re: RFC: Extension Packaging & Lookup

Re: Paul Ramsey > Thanks for this, David, > > > On Oct 28, 2024, at 3:19 PM, David E. Wheeler wrote: > > > > ## Challenge: Third Party Dependencies > > This of course is the area that worries the heck out of me, as someone with > extensions that includes not just single system dependencies but

Re: RFC: Extension Packaging & Lookup

Thanks for this, David, > On Oct 28, 2024, at 3:19 PM, David E. Wheeler wrote: > > ## Challenge: Third Party Dependencies This of course is the area that worries the heck out of me, as someone with extensions that includes not just single system dependencies but long chains of them (depending

Re: RFC: Extension Packaging & Lookup

Greetings Postgres humans, There was much discussion of this proposal at PGConf.eu last week, between Gabriele Bartolini, Peter Eisentraut, Christoph Berg, and Andres Freund (all Cc’d here), and me, among others. We agreed, in principle, to an approach to this feature. Overa

RFC: Extension Packaging & Lookup

Hackers, Back at the end of August, I promised[1]: > I’ll try to put some thought into a more formal proposal in a new thread next > week. Unless your Gabriele beats me to it 😂. I guess I should get off my butt and do it. So let’s do this. Here’s what I propose. * When an extension is insta