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
