NOTIFY with tuples
От | Thomas Munro |
---|---|
Тема | NOTIFY with tuples |
Дата | |
Msg-id | CADLWmXVc+aNcC-tED444V_fWxomf=cBvmh4t-+eWR1ys_VNsWg@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: NOTIFY with tuples
|
Список | pgsql-hackers |
Hi, I've used LISTEN/NOTIFY in a few apps with great success (both the new and the old implementation) but I've found myself wondering why I couldn't use a richer payload, and wondered if anyone already had plans in this direction. It seems there are number of academic and commercial systems (StreamSQL [1], CQL [2], ...) which provide powerful queryable streams of tuples, including windowing, grouping, joining and pipelining facilities, all of which are far beyond what I have been picturing. I imagine a very simple system like this, somehow built on top of the existing NOTIFY infrastructure: CREATE STREAM foo (sensor INTEGER, temperature NUMERIC); In session A: INSERT INTO foo VALUES (42, 99.0); INSERT INTO foo VALUES (99, 100.0); COMMIT; Meanwhile in session B: SELECT * FROM foo; And perhaps even some simple filtering: SELECT * FROM foo WHERE sensor = 42; I don't know how you would first signal your interest in foo before you can start SELECTing from it... perhaps with LISTEN. I suppose running the SELECT query on a stream would return only tuples that are queued up and ready to fetch, without blocking to wait for more, and a client could execute the query repeatedly, using select() on the file descriptor to wait for data to be ready (the same way people currently wait between calls to PGnotifies). As for implementation details, I haven't done much research yet into how something like this would be done and am very new to the source tree, but I thought I'd present this idea and see if it's a duplicate effort, or someone has a much better idea, or it is instantly shot down in flames for technical or other reasons, before investing further in it. Thanks! Thomas Munro [1] http://en.wikipedia.org/wiki/StreamSQL [2] http://de.wikipedia.org/wiki/Continuous_Query_Language
В списке pgsql-hackers по дате отправления: