| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvaro(dot)herrera(at)2ndquadrant(dot)com>, Boris Kolpackov <boris(at)codesynthesis(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add version macro to libpq-fe.h |
| Date: | 2021-06-21 16:43:25 |
| Message-ID: | 701d660a-0306-cd13-3f62-dc71aeb45c76@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6/21/21 12:34 PM, Tom Lane wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 21 Jun 2021, at 17:27, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> What will prevent us from forgetting to do something about this again,
>>> a year from now?
>> An entry in a release checklist could perhaps be an idea?
> Yeah, I was wondering if adding an entry to RELEASE_CHANGES would be
> helpful. Again, I'm not sure that this coding rule is much more
> likely to be violated than any other. On the other hand, the fact
> that it's not critical until we approach release does suggest that
> maybe it'd be useful to treat it as a checklist item.
>
>
Maybe for release note preparation, since that's focused on new
features, but this doesn't sound like a release prep function to me.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2021-06-21 16:50:17 | Re: Discarding DISCARD ALL |
| Previous Message | Tomas Vondra | 2021-06-21 16:42:20 | Re: disfavoring unparameterized nested loops |