Re: Re: proposal: make NOTIFY list de-duplication optional
От | Filip Rembiałkowski |
---|---|
Тема | Re: Re: proposal: make NOTIFY list de-duplication optional |
Дата | |
Msg-id | CAP_rwwnt2ABdoqXTTLbmJDOSk617+6wN=mqjFiT=b5KmuY64wg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: proposal: make NOTIFY list de-duplication optional (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: proposal: make NOTIFY list de-duplication optional
|
Список | pgsql-hackers |
Thank you. Here is my latest attempt, with actual syntax error handling. Also, the syntax is updated to what Tom Lane suggested in other thread (with another variant of the same thing, from Julien Demoor) NOTIFY [ ( option [, ...] ) ] channel [ , payload ] Still no hash table fallback is implemented, so this is *not* a performance improvement. Only a little more flexibility. On Sat, Mar 9, 2019 at 3:31 AM Thomas Munro <thomas.munro@gmail.com> wrote: > > On Fri, Mar 8, 2019 at 1:37 PM Filip Rembiałkowski > <filip.rembialkowski@gmail.com> wrote: > > See attached patch... I'm ready to work on so it can get merged in the next CF. > > Hi Filip, > > Seen on Travis: > > async ... FAILED 126 ms > > Looks like the new error isn't being raised for invalid send mode? > (What kind of error message is "?" anyway? :-)) > > ERROR: channel name too long > -- Should fail. Invalid 3rd parameter > NOTIFY notify_async2, 'test', 'invalid'; > -ERROR: ? > NOTIFY notify_async2, 'test', true; > -ERROR: ? > --Should work. Valid NOTIFY/LISTEN/UNLISTEN commands > NOTIFY notify_async2; > NOTIFY notify_async2, ''; > > -- > Thomas Munro > https://enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: