Re: [PATCH] Refactor pqformat.{c,h} and protocol.h - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: [PATCH] Refactor pqformat.{c,h} and protocol.h
Date
Msg-id CAJ7c6TN6YcMjCwYJuFLwUTrAXUmLKdF2=GRTipmdX1aNB8XUBg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Refactor pqformat.{c,h} and protocol.h  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Refactor pqformat.{c,h} and protocol.h
List 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



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal
Next
From: Nathan Bossart
Date:
Subject: Re: [PATCH] Refactor pqformat.{c,h} and protocol.h