| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Subject: | Re: Use T_IntList for uint32 |
| Date: | 2020-08-31 13:28:43 |
| Message-ID: | 3955127.1598880523@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> Currently pg_list.h doesn't have a variant for uint32 list (like
> T_UIntList), is there a reason other than that that we don't need it
> till now?
I'm not in favor of adding another list variant code just for that;
the overhead is nonzero, and the gain negligible. (I think the reason
we have OID lists is the idea that someday we'd want to make OID 64-bit.
A list type defined as "UInt" would offer no such future-proofing.)
The code you quote probably ought to be casting the result of lfirst_int
to uint32, but I see no reason to work harder.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-08-31 13:39:07 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |
| Previous Message | Ashutosh Bapat | 2020-08-31 13:19:21 | Re: Ideas about a better API for postgres_fdw remote estimates |