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 по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: jsonpath
Следующее
От: David Rowley
Дата:
Сообщение: Re: Performance issue in foreign-key-aware join estimation