| From: | Mitar <mmitar(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Feature request: binary NOTIFY |
| Date: | 2019-09-19 03:46:25 |
| Message-ID: | CAKLmikMsdY18PJQYSgZ97LkeBf03rgPPPoct1Gm-BMuXJALv7g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi!
On Tue, Sep 17, 2019 at 7:10 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah it is ... the internal async-queue data structure assumes
> null-terminated strings. What's a lot worse, so does the
> wire protocol's NotificationResponse message, as well as every
> existing client that can read it. (For instance, libpq's exposed
> API for notify messages hands back the payload as a null-terminated
> string.) I don't think this is going to happen.
Ahh. Any particular reason for this design decision at that time?
What about adding NOTIFYB and LISTENB commands? And
NotificationBinaryResponse? For binary?
Mitar
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2019-09-19 03:47:15 | Re: Optimization of some jsonb functions |
| Previous Message | Alvaro Herrera | 2019-09-19 03:09:06 | Re: Optimization of some jsonb functions |