Re: NOTIFY with tuples

On Tue, Dec 13, 2011 at 11:27 PM, Thomas Munro <munro(at)ip9(dot)org> wrote:
>> Actually, what I'd suggest is just some code to serialize and
>> deserialize tuples and transmit 'em via the existing NOTIFY payload
>> facility.  I agree that presenting it as some functions would be a lot
>> less work than inventing bespoke syntax, but what you sketched still
>> involves writing a lot of communications infrastructure from scratch,
>> and I'm not sure it's worth doing that.
>
> Thank you both for your feedback!
>
> Looking at commands/async.c, it seems as thought it would be difficult
> for function code running in the backend to get its hands on the
> payload containing the serialized tuple, since the notification is
> immediately passed to the client in NotifyMyFrontEnd and there is only
> one queue for all notifications, you can't just put things back or not
> consume some of them yet IIUC.  Maybe the code could changed to handle
> payloads holding serialized tuples differently, and stash them
> somewhere backend-local rather than sending to the client, so that a
> function returning SETOF (or a new executor node type) could
> deserialize them when the user asks for them.  Or did you mean that
> libpq could support deserializing tuples on the client side?

One way of grabbing notifications in a backend function would be via
dblink -- you LISTEN on a sideband connection and grab notifications
via http://www.postgresql.org/docs/9.1/interactive/contrib-dblink-get-notify.html.

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.

merlin