Peter Eisentraut wrote:

Andrew Dunstan wrote:
But the reasons that applied to PL/Java (masses of non-C code was the
main one) probably don't apply in these 2 cases.

I don't think it's the amount of non-C code; it's the amount of code that no one understands. Plus, an argument *for* inclusion was build farm coverage, which I understand will be solved in a different way, applicable to all external modules. Another argument was buzzword compliance, which doesn't apply to these two new candidates. So in summary, while I have not seen any valid reason for these inclusions, there continue to be some against it.


Well, I am not making any promises right now about when buildfarm will support external modules.

My current thinking goes something like this:

. the config file will contain an extra stanza looking something like this:
addons => { <addonname> => { cvsrepo => "<repo locn>", module=> "<modulename>" } ... } . addons will be checked out at the same time as the core, but into a separate directory. We will check them for recent mods in the same way as the core. . after we run "make installcheck" for the core we will run "make" for each addon using the installed pgxs. . after we run "make installcheck" for contrib we will run "make installcheck" for each addon.

(Question - do we restrict addons to those that will build using pgxs?)

Happily, most of the webapp is agnostic about what is reported on - probably adding one db field containing the addon names for the build would suffice.

There are some odd wrinkles. For instance, construction of the URLs for changed files will be somewhat harder. For that reason I think I am going to insist at least in the first instance that all addons must be hosted on pgfoundry where we know perfectly well how to construct cvsweb URLs.There will undoubtedly be more when I get down to it. And we might need to ignore addons for builds on stable branches up to and including 8.2 - I don't know yet.

Now, if someone feels like taking those ideas and running with them in the buildfarm client code they are welcome to drop me a line and I can add them to the project as a developer. Otherwise it will have to wait till I get around to it. That's likely to be some way well into the 8.3 development cycle at the earliest.

And lastly, if we are not going to include these in core, I repeat what I said before: we need to undertake some *serious* evangelising to major packagers to get them to build more than just the core among their standard packages.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to