Re: Function to get size of notification queue?

On Mon, Jun 15, 2015 at 3:16 PM, Brendan Jurd <direvus(at)gmail(dot)com> wrote:
> On Tue, 16 Jun 2015 at 05:36 Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>
>> On Mon, Jun 15, 2015 at 2:12 PM, Alvaro Herrera
>> <alvherre(at)2ndquadrant(dot)com> wrote:
>> > Brendan Jurd wrote:
>> >> However, given the <tumbleweed/> response to my original email,
>> >> it's likely that effort would be a waste of time.
>> >
>> > I think tumbleweed responses are more in line with "hmm, this guy might
>> > well be right, but I don't know right now. <next email>". When people
>> > come up with really useless proposals, they tend to figure out pretty
>> > quickly.
>>
>> +1
>>
>> It took me a lot longer than it should have to figure this out, but
>> lack of comment does not in any way indicate a response is bad. Most
>> commonly it means, "interesting idea, why don't you code it up and see
>> what happens?". Suggestions, even very good ones (except when related
>> to bona fide bugs) are remarkably unlikely to elicit, "good idea,
>> let's do that!".
>
>
> Álvaro, Merlin,
>
> Thanks for your comments. I understand what you're saying, and I do agree
> for the most part. However I've also seen the downside of this, where
> nobody comments much on the original proposal, and only after sinking
> substantial effort into creating a patch do others appear to forcefully
> oppose the idea that led to the patch. I do understand why it happens this
> way, but that doesn't make it any less of a deterrent.
>
> If you see a proposal on the list and you think "interesting idea, why don't
> you code it up and see what happens", I would humbly and respectfully
> encourage you to type exactly those words in to your email client and let
> the author of the proposal know. None of us are telepaths, silence is
> ambiguous, and sometimes even a very small encouragement is all that is
> needed to provoke action.

It goes back to the adage, 'Everyone wants to be an author but nobody
wants to write'. -hackers are busy with release schedules, multi-xact
bugs, bidirectional replication and who knows what else. It's
definitely upon you to do the homework getting patch together, and
you absolutely must be prepared to do that understanding the tough
road most patches have in order to get accepted. The archives clearly
note your suggestion; even if the work gets shelved it can be referred
to by future coders or used as evidence by others to advance work.

For posterity, I think your idea is pretty good, especially if the
current slru based implementation supports it without a lot of extra
work. Adding a new built-in function is not free though so I think to
move forwards with this you'd also have to show some more
justification. Perhaps a real world example demonstrating the problem
reduced down to an executable case.

merlin