Re: signals in ODBC?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Kovacs Zoltan Sandor <tip(at)pc10(dot)radnoti-szeged(dot)sulinet(dot)hu>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: signals in ODBC?
Date: 2000-10-26 14:43:00
Message-ID: 5580.972571380@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Philip Warner <pjw(at)rhyme(dot)com(dot)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

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message kovacsz 2000-10-26 15:00:47 Re: new maintainer for the ODBC driver?
Previous Message Thomas Lockhart 2000-10-26 14:03:49 Re: signals in ODBC?