Re: PostgreSQL 9.3 beta breaks some extensions "make install"

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL 9.3 beta breaks some extensions "make install"
Date: 2013-05-14 19:47:15
Message-ID: CABRT9RCQNoJ71vW=CrvD5FJPgCsaPdRcLYG60YAUxO8arbQAAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
build.sh application/x-sh 794 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-05-14 19:52:06 counting algorithm for incremental matview maintenance
Previous Message Pavel Stehule 2013-05-14 19:43:46 Re: proposal: option --application_name for psql