Re: PSQL commands: \quit_if, \quit_unless
От | Robert Haas |
---|---|
Тема | Re: PSQL commands: \quit_if, \quit_unless |
Дата | |
Msg-id | CA+TgmoZH1X2JgLp_H0EZsJMt+dxU2MZfHi8ocmc5TTGAt8SyDw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PSQL commands: \quit_if, \quit_unless (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: PSQL commands: \quit_if, \quit_unless
|
Список | pgsql-hackers |
On Tue, Dec 6, 2016 at 1:28 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: > First, my experience as a basic patch submitter is that any patch which does > more than one thing at a time, even somehow closely related changes, is > asked to be split into distinct sub-patches, and is harder to get through. > > Second, requiring more advanced features is a recipee for getting nothing in > the end, because even if not "that complex" it requires significant more > time to develop. The first step I outlined is enough to handle the submitted > use case and is compatible with grand plans which would change significantly > psql, so seems a reasonnable intermediate target. > > Your experience as an seasoned core developer and a committer is probably > different:-) Well, everybody can have their own opinion on what is reasonable. There are times I argue for making a patch smaller (frequent) and times when I argue for making it bigger (rare). We had pretty much this exact same argument about the pgbench lexer and parser and in the event I coded something up in less than a day. This argument feels like a rerun of that one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: