Re: NOTIFY with tuples

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.

In response to

Browse pgsql-hackers by date

  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