From: | Thomas Munro <munro(at)ip9(dot)org> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: NOTIFY with tuples |
Date: | 2011-12-14 16:11:32 |
Message-ID: | CADLWmXWMvo5JHh4hivCea7vZ8dUcMv+xAcbFgaw_gYqzg2bAjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14 December 2011 15:10, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> As to the wider point I'm wondering why you can't layer your API on
> top of existing facilities (tables, notifications, etc). PGQ (have you
> seen that?) does this and it's an absolute marvel. Meaning, I bet you
> could do this with an 'all sql (or plpgsql)' implementation. That's a
> good thing -- C code significantly raises the bar in terms of putting
> your code in the hands of people who might be interested in using it.
Well I was interested in the idea of using the NOTIFY payload somehow
for high performance (it's not backed by a table that gets fsynced and
needs to be vacuumed etc, and it delivers data to clients without an
extra round trip), and I guess also really like the idea of streams
being first class objects in a kind of StreamSQL-lite language
extension.
But I've been playing around with Robert's suggestion, and I realised
that I can dress up the foo_read and foo_write functions (probably
written in pure plpgsql) with a VIEW so that I can INSERT and SELECT
tuples, and to be able to join it against other tables. Here's what I
have working so far:
https://github.com/macdice/pg_stream/blob/master/hack.sql
I guess at this point this becomes off topic for pgsql-hackers.
Thanks all for the pointers and ideas.
PGQ looks interesting, I'll check it out.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-12-14 16:14:14 | Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64 |
Previous Message | Simon Riggs | 2011-12-14 16:06:08 | Re: [REVIEW] pg_last_xact_insert_timestamp |