Alexander Cheshev <alex.cheshev@gmail.com> writes:
> [ v4-0001-Support-wildcards-in-LISTEN-command.patch ]
I had not been paying much if any attention to this thread.
I assumed from the title that it had in mind to allow something like
LISTEN "foo%bar";
where the parameter would be interpreted similarly to a LIKE pattern.
I happened to look at the current state of affairs and was rather
astonished to find how far off those rails the proposal has gotten.
Where is the field demand for N-part channel names? If we do accept
that, how well do you think it's going to work to continue to
constrain the total name length to NAMEDATALEN? Why, if you're
building a thousand-line patch, would you have arbitrary pattern
restrictions like "% can only appear at the end of a name part"?
What makes you think it's okay to randomly change around unrelated
parts of the grammar, scansup.c, etc? (The potential side-effects
of that scare me quite a bit: even if you didn't break anything,
the blast radius that a reviewer has to examine is very large.)
I've also got serious doubts about the value of the trie structure
you're building to try to speed up name matching. I haven't seen
any evidence that channel name matching is a bottleneck in NOTIFY
processing (in a quick test with "perf", it's not even visible).
I do think the net effect of a patch like this would be to slow things
down, but mostly because it would encourage use of overly-verbose
channel names and thereby increase the amount of data passing through
the notify SLRU.
I think this is dramatically over-engineered and you ought to
start over with a much simpler concept. The fact that one person
ten years ago asked for something that used exactly ASP.NET's
notation doesn't mean that that's exactly how we need to do it.
(There's a separate discussion to be had about whether the
whole issue is really worth bothering with, given the rather
low field demand. But it'd be a lot easier to justify a
hundred-line patch than this thing.)
regards, tom lane
