On Tue, Dec 6, 2016 at 1:28 AM, Fabien COELHO <coe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
