I think you're making a mountain out of a molehill. I implemented this today in about three hours.

I think you're greatly understating your own efficiency at shift/reducing parser mountains down to molehills. Fabien even guessed the LOC size of the resulting patch with less than a 9% error.

As I do research and also teach compilers, it was not that hard for me to provide a reasonable size estimation.

A also noticed Robert's 3 lines per minutes outstanding productivity. Once you include argumenting, testing, debuging and documenting, that may go down a bit, but it is very good anyway.

You can also notice that in the patch the handling of '%' involves 11 lines (1 lexer, 1 parser, 9 executor), basically the very same size as the patch I submitted, for a very similar code.

[...]. Yes, the PostgreSQL community is hostile to short, targeted feature improvements unless they come already fit into a large, standards compliant strategy for improving the database. That doesn't work well when approached by scratch an itch stye development.

Indeed I tend to avoid spending hours on something when I can spend minutes, and if I spend hours I'm really cross if a patch is rejected, whereas I'm less crossed if I just lost minutes.

I had bad experiences with patch submissions in the past when "things are changed and someone does not want it", and it seems that this patch falls
within this risk, hence my reluctance to spend the time.

Now, as the patch is submitted by a core dev, I think the likelyhood that some version will be committed is high, so all is well, and I gladly review and test it when I have time, alas not in the short term.

--
Fabien.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to