Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154])
	by hub.org (8.10.1/8.11.0) with ESMTP id e9QEiVU72067
	for <pgsql-interfaces@postgresql.org>;
	Thu, 26 Oct 2000 10:44:31 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id e9QEh0505583;
	Thu, 26 Oct 2000 10:43:00 -0400 (EDT)
To: Philip Warner <pjw@rhyme.com.au>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
	Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>,
	pgsql-interfaces@postgresql.org
Subject: Re: signals in ODBC? 
In-reply-to: <3.0.5.32.20001027010536.03c06c00@mail.rhyme.com.au> 
References: <39F6F11D.79C5800B@alumni.caltech.edu>
	<Pine.LNX.4.05.10010251411460.30412-100000@pc10.radnoti-szeged.sulinet.hu>
	<39F6F11D.79C5800B@alumni.caltech.edu>
	<3.0.5.32.20001027010536.03c06c00@mail.rhyme.com.au>
Comments: In-reply-to Philip Warner <pjw@rhyme.com.au>
	message dated "Fri, 27 Oct 2000 01:05:36 +1000"
Date: Thu, 26 Oct 2000 10:43:00 -0400
Message-ID: <5580.972571380@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Archive-Number: 200010/225
X-Sequence-Number: 1584

Philip Warner <pjw@rhyme.com.au> writes:
> ODBC 1 & 2 don't. I doubt 3 does either. What would be really kind of nice
> is if we had:
>     LISTEN <name> [<port>]
> which would send notifications to the specified port on the client machine.
> Then with a small amount of effort, ODBC users could take advantage of
> notifications. Does this sound easy/hard and worthwhile?

Not sure I see the point.  If there's to be a separate connection, you
might as well just fire up a libpq connection.  Someone else already
pointed out that you could use ODBC for your main data transfer, if you
like ODBC, and use a second connection through libpq only to get
notifications.

AFAIK there's no fundamental reason that NOTIFY support couldn't be
added to our ODBC driver, it's just that it would fall outside the
ODBC API spec.  But then a second connection through libpq isn't ODBC
compliant either.

My vote would be to spend time updating the driver, rather than adding
a wart onto the backend's LISTEN support.

			regards, tom lane