No I was thinking just message from mariaDB server to another app, never to be used as a gateway between two apps.

And Yes It will be related to tables, for example if could be used by SQL Monitors or Benchmark tools.
But also could help to send infor for other stuff, but always related to data that is being updated in tables.

Another useful example that can be used with MariaDB is that, there is no built-in commands to execute OS commands, this is for security reasons.
But we as develoeprs can Create an application that its only purpose will be only to run commands. for example create folders in the server storage device, so we can generate files from a stored procedure and store them to a specific folder. Inside that stored procedure we can send a Push notification, so we can tell the App to execute certain command. It can be to create a folder, or to move a file from a specific folder to a new one.
A special execution permission can be added so only Granted users can execute a Push notifications.

I added a related task request - MDEV-23545.

But I would still like to see this Notify/Listen mechanism implemented in MariaDB. Postgres isn't the only database to implement this kind of feature, there is also:

• Oracle Database Continuous Query Notification
• SQL Server waitfor/receive

This could be implemented as per comment https://jira.mariadb.org/browse/MDEV-23545?focusedCommentId=164026&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-164026 on https://jira.mariadb.org/browse/MDEV-23545 in the Mechanics Progress section - using TableWait/TableSignal.

That is:

• No data to send - simpler to implement - followup with SELECT
• Partitioned per-table (and per schema) - enabling fine-grained security enforcement. Should User B know that a new Sale record was inserted?

Ideally this would become some sort of standard SQL too:

CREATE SIGNAL Inserted ON mydb.Sales 

GRANT WAIT * On mydb.Sales TO 'User B'

GRANT WAIT * On mydb.* TO 'User C'

GRANT WAIT Inserted On mydb.* TO 'User D'

GRANT PULSE * On mydb.Sales TO 'User E'

GRANT PULSE * On mydb.* TO 'User F'

GRANT PULSE Inserted On mydb.* TO 'User G'

WAIT Inserted ON mydb.Sales TIMEOUT 300 -- or the default, NO TIMEOUT

-- Somewhere else

PULSE Inserted On mydb.Sales

A gust post from Percona - https://blog.engineyard.com/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you

First, let’s look at how to avoid polling. I wish that MySQL had listen/notify functionality, the way that PostgreSQL and Microsoft SQL Server do (just to mention two). Alas, MySQL doesn’t, but you can simulate it. Here are three ideas: [i] use GET_LOCK() and RELEASE_LOCK(), or [ii] write a plugin to communicate through Spread, or [iii] make the consumers run a SLEEP(100000) query, and then kill these queries to “signal” to the worker that there’s something to do