Re: First draft of PG 17 release notes
От | Jelte Fennema-Nio |
---|---|
Тема | Re: First draft of PG 17 release notes |
Дата | |
Msg-id | CAGECzQQ-ec-=HKRaD3y7b_Z5Vo4HxztAknG04RVG3HLwJvsguw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: First draft of PG 17 release notes (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: First draft of PG 17 release notes
|
Список | pgsql-hackers |
On Wed, 11 Sept 2024 at 16:10, Bruce Momjian <bruce@momjian.us> wrote: > You are right that I do mention changes specifically designed for the > use of extensions, but there is no mention in the commit message of its > use for extensions. In fact, I thought this was too low-level to be of > use for extensions. However, if people feel it should be added, we have > enough time to add it. Another new API that is useful for extension authors is the following one (I'm obviously biased since I'm the author, and I don't know if there's still time): commit 14dd0f27d7cd56ffae9ecdbe324965073d01a9ff Author: Nathan Bossart <nathan@postgresql.org> Date: Thu Jan 4 16:09:34 2024 -0600 Add macros for looping through a List without a ListCell. Many foreach loops only use the ListCell pointer to retrieve the content of the cell, like so: ListCell *lc; foreach(lc, mylist) { int myint = lfirst_int(lc); ... } This commit adds a few convenience macros that automatically declare the loop variable and retrieve the current cell's contents. This allows us to rewrite the previous loop like this: foreach_int(myint, mylist) { ... } > An interesting idea would be > to report all function signature changes in each major release in some > way. I think that might be useful, but it very much depends how long that list gets. If it gets too long I think authors will just try to compile and only look at the ones that break for them.
В списке pgsql-hackers по дате отправления: