From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Subject: | Re: [PATCH] Refactor pqformat.{c,h} and protocol.h |
Date: | 2024-07-16 17:21:50 |
Message-ID: | CAJ7c6TN6YcMjCwYJuFLwUTrAXUmLKdF2=GRTipmdX1aNB8XUBg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
> > This was briefly brought up in the discussion that ultimately led to
> > protocol.h [0]. I don't have a particularly strong opinion on the matter,
> > but I will note that protocol.h was intended to be easily usable in
> > third-party code, and changing it from characters to an enum from v17 to
> > v18 might cause some extra code churn.
>
> We could avoid that issue by back-patching into 17; I don't think
> it's quite too late for that, and the header is new as of 17.
>
> However, I'm generally -1 on the proposal independently of that,
>
> [...]
>
> (This applies only to the s/char/enum/ proposal; I've not read
> the patchset further than that.)
That's fair enough. Also it's not clear how much type safety enums
give us exactly. E.g. after applying 0002 pq_putmessage() a.k.a.
PQcommMethods->putmessage() silently casts its first argument from
`enum PqMsg` to `char` (shrug).
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-07-16 17:34:12 | Re: [PATCH] Refactor pqformat.{c,h} and protocol.h |
Previous Message | Fujii Masao | 2024-07-16 17:16:27 | Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal |