"David E. Wheeler" <da...@kineticode.com> writes: > Just so long as you're aware that you might get more challenges on this going > forward.
Sure, thanks for the reminder. That said I also remember the reaction when I used to scan the SHARE/contrib directory to find the extension control file having the right name property, and I don't see scanning the same directory in order to find out which upgrade file to consider depending on several parts of its name as so different. Current code allows you to use the same upgrade script for more than one source version, and does so in a way that it's easy to determine which upgrade file to seek for. >> I don't see the benefit of having the 'relocatable' property optional in >> the control file, but I see a huge drawback. Requiring it will force >> extension authors to at least have a glance at the docs to understand >> how to set it. It's important not to overlook it. > > I guess. I'll have to think about how to support it in PGXN, though. And the > upgrade keys if they stay in. Disclaimer: the following is based on my understanding of how you want to bundle things, from several discussions we had together at pubs or on IRC, please don't read further if you're changed your mind about generating the control file from your PGXN YAML specification. Well, I think you're having a dependency inversion problem here. PGXN depends on extensions, not the other way round. Also, I really expect the extension facility to be mainly used for internal proprietary code, mainly procedure collections, and only occasionaly for publishing Open Source components. So you should be considering the control file as an input to your processes, a source file, not something that your service will hide for extension authors: there's no benefit that I can see in doing so. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
