On Tue, May 14, 2013 at 2:59 PM, Peter Eisentraut <peter_e@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
