twitter_fdw apparently not working
Gianni Ciolli
$ pgxn install www_fdw
David E. Wheeler
Does this work?
USE_PGXS=1 pgxnclient install twitter_fdw
The PostgreSQL hackers told me that USE_PGXS=1 is deprecated. So none of the PGXN docs mention it. (Or if they do, it’s a bug; please report it!). I've reported this to the twitter_fdw project:
https://github.com/umitanuki/twitter_fdw/issues/4
But I know that quite a few extensions are modeled on the contrib stuff in core, which uses USE_PGXS for its own purposes. So it might be worth considering setting that environment variable in pgxnclient, just to cover for those folks who haven’t caught on yet.
Daniele, what do you think?
Best,
David
Daniele Varrazzo
Hi Gianni, nice to read you again,
> On Tue, Mar 27, 2012 at 08:32:42PM -0700, David E. Wheeler wrote:
>> But I know that quite a few extensions are modeled on the contrib
>> stuff in core, which uses USE_PGXS for its own purposes. So it might
>> be worth considering setting that environment variable in
>> pgxnclient, just to cover for those folks who haven’t caught on yet.
>
> IMHO a mention in the docs will do, so that people don't have do
> bother pgxn when in fact the problem is on the particular extension.
What I think is that I should document, if not explicit enough, that
all that pgxn does build-wise is a configure, make cycle. If configure
and make are not enough, the client cannot work with the exception.
twitter_fdw used to require setting USE_PGXS=1 externally to work
instead (as you have easily verified). The requirement has been fixed
upstream [1] so now there should be no problem.
I had never seen before the requirement to set USE_PGXS externally.
I've started writing my own exception "taking inspiration" (downright
copying) from the contrib modules, and what I'd seen was to set
USE_PGXS=1 in the makefile and let the magic go; I've never seen a
conditional use for it before.
Because what is obvious for me is probably less obvious for the users,
I'd be happy to accept docs patches to make more obvious the
requirement that make (and optionally configure) ought to be the only
required build steps and also the suggestion to run pgxn with the
--verbose option to have all the commands printed, so it can be easy
to debug the wrong steps.
[reviewing the docs...] Currently there is something into the "pgxn
install" docs [2], but probably is too buried away. What could be
useful is probably a section "How to make your extension working with
pgxn client". There is no hint that --verbose prints the commands
executed I think.
Cheers,
-- Daniele
[1] https://github.com/umitanuki/twitter_fdw/commit/83022a1675f4c8700a96618076fa9c26a6a7a27a
[2] http://pgxnclient.projects.postgresql.org/usage.html#pgxn-install
David E. Wheeler
> [reviewing the docs...] Currently there is something into the "pgxn
> install" docs [2], but probably is too buried away. What could be
> useful is probably a section "How to make your extension working with
> pgxn client". There is no hint that --verbose prints the commands
> executed I think.
Makes sense. We should probably make sure that the PGXN docs about the same topic are in sync.
Best,
David
Hitoshi Harada
<daniele....@gmail.com> wrote:
> On Wed, Mar 28, 2012 at 8:28 AM, Gianni Ciolli <gici...@gmail.com> wrote:
>
> Hi Gianni, nice to read you again,
>
>> On Tue, Mar 27, 2012 at 08:32:42PM -0700, David E. Wheeler wrote:
>
>>> But I know that quite a few extensions are modeled on the contrib
>>> stuff in core, which uses USE_PGXS for its own purposes. So it might
>>> be worth considering setting that environment variable in
>>> pgxnclient, just to cover for those folks who haven’t caught on yet.
>>
>> IMHO a mention in the docs will do, so that people don't have do
>> bother pgxn when in fact the problem is on the particular extension.
>
> What I think is that I should document, if not explicit enough, that
> all that pgxn does build-wise is a configure, make cycle. If configure
> and make are not enough, the client cannot work with the exception.
> twitter_fdw used to require setting USE_PGXS=1 externally to work
> instead (as you have easily verified). The requirement has been fixed
> upstream [1] so now there should be no problem.
Yes, I removed USE_PGXS option and uploaded new version to PGXN.
Thanks for suggestions. I agree we don't need it and twitter_fdw was
from old school days. Now that we have a good command line tool to
create template, I don't think a lot of developer will go into the
same direction anymore.
Thanks,
--
Hitoshi Harada
Gianni Ciolli
On Wed, Mar 28, 2012 at 10:59:30AM +0100, Daniele Varrazzo wrote:
> On Wed, Mar 28, 2012 at 8:28 AM, Gianni Ciolli <gici...@gmail.com> wrote:
>
> Hi Gianni, nice to read you again,
same here :-)
> > On Tue, Mar 27, 2012 at 08:32:42PM -0700, David E. Wheeler wrote:
>
> >> But I know that quite a few extensions are modeled on the contrib
> >> stuff in core, which uses USE_PGXS for its own purposes. So it might
> >> be worth considering setting that environment variable in
> >> pgxnclient, just to cover for those folks who haven’t caught on yet.
> >
> > IMHO a mention in the docs will do, so that people don't have do
> > bother pgxn when in fact the problem is on the particular extension.
>
> What I think is that I should document, if not explicit enough, that
> all that pgxn does build-wise is a configure, make cycle. If configure
> and make are not enough, the client cannot work with the exception.
I agree. Now that I have grasped the problem, I believe the casual
user would find a remark like this useful:
Many distributions currently require the user to specify USE_PGXS=1
at build time because they don't assume that PGXS is always
available.
This is now deprecated, and distributions are currently being
upgraded so that they do not require USE_PGXS=1.
As a temporary workaround you can set that variable in the
invocation of pgxnclient, as in the following example:
$ USE_PGXS=1 pgxnclient install mydistrib
Cheers,
Gianni
Gianni Ciolli
>
> > I'd like to report a problem; not sure if it is with pgxn, with pgxnclient or with the particular distribution itself.
> >
> > I cannot install twitter_fdw with pgxnclient:
> > gianni@albo:~$ pgxnclient install twitter_fdw
> > INFO: best version: twitter_fdw 1.0.0
> > INFO: saving /tmp/tmp3Po187/twitter_fdw-1.0.0.zip
> > INFO: unpacking: /tmp/tmp3Po187/twitter_fdw-1.0.0.zip
> > INFO: building extension
> > Makefile:29: ../../src/Makefile.global: No such file or directory
> > Makefile:30: /contrib/contrib-global.mk: No such file or directory
> > make: *** No rule to make target `/contrib/contrib-global.mk'. Stop.
> > ERROR: command returned 2: make PG_CONFIG=pg_config all
> >
> > Note that twitter_fdw compiles manually with
> > $ make USE_PGXS=1
> >
> > and that a "similar" distribution can instead installed with pgxnclient:
> > $ pgxn install www_fdw
>
> Does this work?
>
> USE_PGXS=1 pgxnclient install twitter_fdw
Yes, it does. Thanks.
Then the reason is that the twitter_fdw package requires USE_PGXS=1,
unlike www_fdw.
> The PostgreSQL hackers told me that USE_PGXS=1 is deprecated. So
> none of the PGXN docs mention it. (Or if they do, it’s a bug; please
> report it!).
Ah, I missed that conversation :-) But clearly it makes sense to
assume PGXS.
> I've reported this to the twitter_fdw project:
>
> https://github.com/umitanuki/twitter_fdw/issues/4
Thanks for reporting it. I would have done it myself (but I didn't
know where the problem was).
> But I know that quite a few extensions are modeled on the contrib
> stuff in core, which uses USE_PGXS for its own purposes. So it might
> be worth considering setting that environment variable in
> pgxnclient, just to cover for those folks who haven’t caught on yet.
IMHO a mention in the docs will do, so that people don't have do
bother pgxn when in fact the problem is on the particular extension.
Cheers,
Gianni