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
