Re: Listen / Notify rewrite

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joachim Wieland <joe(at)mcknight(dot)de>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Chernow <andrew(at)esilo(dot)com>
Subject: Re: Listen / Notify rewrite
Date: 2009-11-12 16:38:25
Message-ID: 937d27e10911120838m5709e59aj74a7ec305757dfdc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 12, 2009 at 4:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> So while a payload string for NOTIFY has been on the to-do list since
> forever, I have to think that Greg's got a good point questioning
> whether it is actually a good idea.

Here's an example of why I'd like a payload (and not a queue in an
add-on module). Say you have multiple users running pgAdmin. One of
them creates a new table. Currently, unless the other user refreshes
his view of the database, he won't see it. I'd like to be able to
notify the other pgAdmin sessions that a new table has been created,
so they can automatically display it, without having to poll pg_class
or be manually refreshed. The payload could contain details of type of
object that has been created, and it's OID/identifier to minimise the
work required of the other sessions to find and display the new
object.

And as I'm sure you're already thinking it, yes, I know it doesn't
help if the new table is created using psql, but there are lots of
shops where pgAdmin is the default tool, and it could help them and
just exhibit the current behaviour if someone does break out psql.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-11-12 16:39:00 Re: Listen / Notify rewrite
Previous Message Selena Deckelmann 2009-11-12 16:37:32 Re: next CommitFest