Re: Proposal of new PostgreSQL Extension - PGSpiderExt

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Adam Brusselback <adambrusselback(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal of new PostgreSQL Extension - PGSpiderExt
Date: 2020-09-19 04:14:58
Message-ID: CAFj8pRArKm6c+6-3UweWrSM5_MuEFYmSNJmzdSgNUFXJExYQ=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

so 19. 9. 2020 v 0:42 odesílatel Bruce Momjian <bruce(at)momjian(dot)us> napsal:

> On Wed, Sep 16, 2020 at 05:40:30PM +0200, Pavel Stehule wrote:
> > May be I am wrong, but it seems to me that not so much people know
> about
> > pgxn.org
> > Before writing this mail I have tried to locate such resource in
> Google and
> > didn't succeed.
> >
> > yes, It is not strongly joined with the Postgres community, and it
> doesn't
> > deploy binary (compiled) code if I know it. So for some people it is not
> > usable.
> >
> > But anytime this and similar repositories will have problems, because the
> > extensions there are not reviewed, nobody did security check, nobody did
> QA.
> >
> > This is useful for Postgres developers, for very advanced users, or for
> very
> > fearless users :).
>
> I think if PGXN had more must-have extensions, its popularity would
> increase.
>

There is nothing else. But it can be much more useful, if somebody does
review, or if allows compilation to target platform on server side, if has
integrated tests, ...

Regards

Pavel

> --
> Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
> EnterpriseDB https://enterprisedb.com
>
> The usefulness of a cup is in its emptiness, Bruce Lee
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-09-19 05:06:10 Re: Handing off SLRU fsyncs to the checkpointer
Previous Message Thomas Munro 2020-09-19 03:55:24 Re: Division in dynahash.c due to HASH_FFACTOR