Re: proposal: make NOTIFY list de-duplication optional
От | Vik Fearing |
---|---|
Тема | Re: proposal: make NOTIFY list de-duplication optional |
Дата | |
Msg-id | 56B764BA.9070800@2ndquadrant.fr обсуждение исходный текст |
Ответ на | Re: proposal: make NOTIFY list de-duplication optional (Filip Rembiałkowski <filip.rembialkowski@gmail.com>) |
Ответы |
Re: proposal: make NOTIFY list de-duplication optional
|
Список | pgsql-hackers |
On 02/07/2016 04:00 PM, Filip Rembiałkowski wrote: > On Sun, Feb 7, 2016 at 11:54 AM, Vik Fearing <vik@2ndquadrant.fr> wrote: >> I seem to remember some discussion about not using DEFAULT parameters in >> system functions so you should leave the old function alone and create a >> new function with your use_all parameter. I don't recall the exact >> reason why so hopefully someone else will enlighten me. > > I'm quite new to this; how do I pinpoint proper OID for a new catalog > object (function, in this case)? > Is there a better way than browsing fmgr files and guessing next available oid? There is a shell script called `unused_oids` in src/include/catalog/. >> There is also no mention in the documentation about what happens if I do: >> >> NOTIFY ALL chan, 'msg'; >> NOTIFY ALL chan, 'msg'; >> NOTIFY DISTINCT chan, 'msg'; >> NOTIFY ALL chan, 'msg'; >> >> Without testing, I'd say I'd get two messages, but it should be >> explicitly mentioned somewhere. > > If it's four separate transactions, LISTEN'er should get four. The question was for one transaction, I should have been clearer about that. > If it's in one transaction, LISTEN'er should get three. This is surprising to me, I would think it would get only two. What is your rationale for three? Compare with the behavior of: select 1 union all select 1 union distinct select 1 union all select 1; -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: