Обсуждение: Feature request: binary NOTIFY
Hi! I might have missed prior discussions about this, but I wonder if it would be possible to support binary payloads for NOTIFY/LISTEN? Again and again I find it very limiting with just text (have to base64 encode data, or convert it to JSON). Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Hi
út 17. 9. 2019 v 10:01 odesílatel Mitar <mmitar@gmail.com> napsal:
Hi!
I might have missed prior discussions about this, but I wonder if it
would be possible to support binary payloads for NOTIFY/LISTEN? Again
and again I find it very limiting with just text (have to base64
encode data, or convert it to JSON).
I think so is not any problem to pass binary data already. Text type "text" and binary type "bytea" is internally very similar.
But the message doesn't any info about type, so it should be ensure so clients understand to message and takes data in binary format.
You can overwrite pg_notify function for bytea format.
Is not possible to use NOTIFY with binary data, because this statement doesn't allow parametrization
Pavel
Pavel Stehule <pavel.stehule@gmail.com> writes:
> út 17. 9. 2019 v 10:01 odesílatel Mitar <mmitar@gmail.com> napsal:
>> I might have missed prior discussions about this, but I wonder if it
>> would be possible to support binary payloads for NOTIFY/LISTEN? Again
>> and again I find it very limiting with just text (have to base64
>> encode data, or convert it to JSON).
> I think so is not any problem to pass binary data already.
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.
regards, tom lane
út 17. 9. 2019 v 16:10 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes:
> út 17. 9. 2019 v 10:01 odesílatel Mitar <mmitar@gmail.com> napsal:
>> I might have missed prior discussions about this, but I wonder if it
>> would be possible to support binary payloads for NOTIFY/LISTEN? Again
>> and again I find it very limiting with just text (have to base64
>> encode data, or convert it to JSON).
> I think so is not any problem to pass binary data already.
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.
ok, thank you for correction.
Regards
Pavel
regards, tom lane
Hi! On Tue, Sep 17, 2019 at 7:10 AM Tom Lane <tgl@sss.pgh.pa.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 -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Mitar <mmitar@gmail.com> writes:
> What about adding NOTIFYB and LISTENB commands? And
> NotificationBinaryResponse? For binary?
[ shrug... ] We can put that on the list of things we might want
to do if the wire protocol ever gets changed. I urgently recommend
not holding your breath.
regards, tom lane
Hi! On Wed, Sep 18, 2019 at 9:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > [ shrug... ] We can put that on the list of things we might want > to do if the wire protocol ever gets changed. I urgently recommend > not holding your breath. What is the process to add it to the list? And yes, I will not expect it soon. :-) Thanks. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m