On Tue, May 14, 2013 at 2:59 PM, Peter Eisentraut <pete...@gmx.net> wrote: >> Perhaps, but fixing the extensions is not a solution at this point. A >> large number of extensions use this exact code (it comes from David >> Wheeler's template AFAIK). > > So far, the number is still less than the number of extensions broken by > the htup header refactoring, so I'm not worried about it.
I think that's fair. The C API has always been in flux and there are no stability guarantees. We expect C extension writers to know what they're doing. But I think we should be more forgiving to extensions written in "stable" languages like PL/pgSQL, especially if they break *because* the writer was following PGXN packaging best practices (http://manager.pgxn.org/howto) and not a fault of their own. I did a quick and dirty survey of extensions on PGXN and found that the install change causes problems for (at least) 22% of extensions there. I think it's well worth the time to implement a workaround, rather than hassle extension writers. --- I downloaded and tried to build the latest version of each package on PGXN (103 total). Now obviously I can't build everything because I don't have all the necessary dependencies -- which means it's probably skewed against C extensions. So don't take these results too seriously. But a it's data point regardless: 9.2 9.3beta1 70 61 <-- "make" succeeds 65 33 <-- "make install" succeeds 0 23 <-- outputs "install: will not overwrite just-created" 0 7 <-- outputs "implicit declaration of function 'heap_" Note that the htup change causes just a compile-time warning (it will fail at extension load time), so some of these are counted as successful builds. Script and some instructions to replicate this test are attached. Regards, Marti
build.sh
Description: Bourne shell script
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
