Re: [submit code] I develop a tool for pgsql, how can I submit it - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: [submit code] I develop a tool for pgsql, how can I submit it
Date
Msg-id CAHE3wgjGWEAj7L5+L7PEBHKtuvqUEFOHJdRLHfb_7TFT-3NHQA@mail.gmail.com
Whole thread Raw
In response to [submit code] I develop a tool for pgsql, how can I submit it  (leap <leapking@126.com>)
List pgsql-hackers
2018-03-13 12:19 GMT-03:00 leap <leapking@126.com>:
> I develop a tool for pgsql, I want to submit it on pgsql.
> how can I submit it?
>
As Laurenz said a tool doesn't necessarily have to be part of
PostgreSQL. Sometimes a lot of people ask for a tool, someone write it
and the community decide to maintain it. I'm not sure this is the case
for your tool. The pro is that the tool will be maintained by a group
of experienced programmers (I'm not saying you can't have this group
outside PostgreSQL project. You may have enough interest if people are
excited by it). The con about this direction is that the tool
development cycle is tied to PostgreSQL (which means 1-year cycle and
slow development over time). Since I do a lot of debug it seems very
useful for me. If you decide to convince people about the usefulness
of your tool, you should: (i) remove some overlap between the tool and
core, (ii) cleanup your code to follow the PostgreSQL guidelines,
(iii) reuse core functions, (iv) reuse constants instead of redefine
them and (v) document everything. Steps (i), (iii) and (iv) may
require some code rearrange in PostgreSQL. Even if you decide to
continue the development outside PostgreSQL, those steps would improve
your code.


-- 
   Euler Taveira                                   Timbira -
http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: neqjoinsel versus "refresh materialized view concurrently"
Next
From: Andrew Dunstan
Date:
Subject: Re: ALTER TABLE ADD COLUMN fast default