| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: table AM option passing |
| Date: | 2026-03-18 21:17:40 |
| Message-ID: | absWdP4uVsmiDW9A@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 17, 2026 at 05:09:49PM -0400, Andres Freund wrote:
> Personally I object to the existence of the bits* types, to me they're just
> noise over using the corresponding unsigned integer types. One more thing that
> one has to just know what it means without there being any actual improved
> type checking or such. It's not like using bits* would make it any easier to
> make the underlying type a struct or such (which is different to
> e.g. TransactionId, we could probably replace that with a struct without crazy
> amounts of trouble).
Yeah, I don't see why you'd prefer bits32 over uint32. If anything, uint32
is probably less confusing because most hackers will have used it before.
AFAICT the bits* types are a relic of the 80s, and there used to be other
types like bool8 and word32, all of which were just uint* behind the
scenes. Those were removed in 2004 by commit ca7a1f0c86. I assume bits*
was left behind because it was still in use.
> I think we should just rip the bits* types out and replace them with the
> underlying types.
+1. If there seems to be consensus, I'm happy to write the patch.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Tom Lane | 2026-03-18 21:15:57 | Re: SQL Property Graph Queries (SQL/PGQ) |