"David E. Wheeler" <david@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
hadtogether at pubs or on IRC, please don't read further if you're changed your mind about generating the control file
fromyour 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